Bug 537363

Things that make you go hmmm...

> sed -i -e '/ldconfig/d' Makefile.template

And later:

> # Add missing symlinks
> ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so.0
> ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so
> ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so.0
> ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so
> ln -sf libpaq.so.0.0.0 %{buildroot}%{_libdir}/libpaq.so.0

:)

Actually, that's why the Makefile ran "ldconfig -n" in libdir to create the symlinks for the shared libpaq. With ldconfig, it would reduce to

/sbin/ldconfig -n %{buildroot}%{_libdir}
ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so
ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so

at the end of %install. The two "ln -s" are left only because those two shared libs are built manually in the spec file.

[...]

Upstream is funny so to say:

http://ll-plugins.nongnu.org/dox/lv2-c++-tools/1.0.2/

| These libraries are only available as static libraries (and most
| of the code is template classes in header files), thus ABI stability
| is not an issue. The API will be stable between major version bumps,
| at which the pkg-config name would change to prevent plugins from
| building against an incompatible version, but if you were to modify
| the build system to create shared libraries and link against those
| you are on your own.

Translates to ''I don't really want this API to be used by any C++ application'' as all library updates will require app rebuilds, and API changes will require additional updates in build frameworks.

(In reply to comment #1)

Thanks for having a look

> Things that make you go hmmm...
> 
> > sed -i -e '/ldconfig/d' Makefile.template
> 
> And later:
> 
> > # Add missing symlinks
> > ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so.0
> > ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so
> > ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so.0
> > ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so
> > ln -sf libpaq.so.0.0.0 %{buildroot}%{_libdir}/libpaq.so.0
> 
> :)
> 
> Actually, that's why the Makefile ran "ldconfig -n" in libdir to create the
> symlinks for the shared libpaq. With ldconfig, it would reduce to
> 
> /sbin/ldconfig -n %{buildroot}%{_libdir}
> ln -sf liblv2-gui.so.0.0.0 %{buildroot}%{_libdir}/liblv2-gui.so
> ln -sf liblv2-plugin.so.0.0.0 %{buildroot}%{_libdir}/liblv2-plugin.so
> 
> at the end of %install. The two "ln -s" are left only because those two shared
> libs are built manually in the spec file.
> 
> [...]
> 

oops. I guess it's my sloppiness again. I didn't notice the -n flag and I thought it was trying to rebuild the cache which would need root access. I'll remove the unnecessary lines.

> Upstream is funny so to say:
> 
> http://ll-plugins.nongnu.org/dox/lv2-c++-tools/1.0.2/
> 
> | These libraries are only available as static libraries (and most
> | of the code is template classes in header files), thus ABI stability
> | is not an issue. The API will be stable between major version bumps,
> | at which the pkg-config name would change to prevent plugins from
> | building against an incompatible version, but if you were to modify
> | the build system to create shared libraries and link against those
> | you are on your own.
> 
> Translates to ''I don't really want this API to be used by any C++
> application'' as all library updates will require app rebuilds, and API 
> changes will require additional updates in build frameworks.  

I am really not sure what would be the best approach here. I can leave them as static libs but Fedora doesn't really like static libs. Or just make shared libs despite the warning of upstream. For the time being, it is safe to do so since the only software that uses the library is made by the same author.


By the way I noticed that the build hangs in F-12 at
   ar rcs libraries/lv2gui/liblv2-gui.a libraries/lv2gui/lv2gui.o
It doesn't fail but it just stays there forever. When I make the build on F-11, it passes through that line without much delay. I don't know where the problem is. Any opinions?

So, it *really* hangs? - I've experienced a long build-time with F12 i686, too, but g++/ccache was still sucking a lot of cpu power and memory on an already busy machine, so I killed the build and restarted it without ccache and with optflags=-g only. That had managed to build something before I returned.

Will need another look it seems.

Yes, it hangs when -O2 is present. Did they modify the -O2 bundle recently because the same code compiles in F-11? 

I didn't have time to look into this further but I will.

Spec URL: http://oget.fedorapeople.org/review/lv2-c++-tools.spec
SRPM URL:
http://oget.fedorapeople.org/review/lv2-c++-tools-1.0.3-1.fc11.src.rpm

Updated to 1.0.3. Not much changed softwarewise. I added a patch that fixes bunch of warnings about some boost headers. The patch is sent upstream. I also worked around the compiler bug with the -fno-var-tracking-assignments flag.

As for the static/dynamic library, I asked upstream about this and I am waiting for their response. But I vote for going for dynamic libraries. Not much software depends on this.

Sorry the SRPM URL should be
http://oget.fedorapeople.org/review/lv2-c++-tools-1.0.3-1.fc12.src.rpm

Hi, I got a hold of the project developer and he requested me to leave the two libraries static, as otherwise things might break. Here is what he says:

> Well, I don't think I'll ever make the libraries shared by default -
> there are reasons for having them static other than ABI instability. I
> don't think that the gain in file size and maintainability in separating
> such a tiny piece of code (two 2-line functions and one 3-line function
> for liblv2-plugin.a, one 2-line function and one 4-line function for
> liblv2-gui.a) justifies the additional annoyance of having an extra
> runtime dependency for every plugin built using the libraries (more of
> an annoyance for people who build from source than for those who use
> package managers obviously).
>
> Also, when looking at the code I remembered a reason why it's not a good
> idea to build the current code as shared libraries. liblv2-plugin.a
> contains a symbol, LV2::get_lv2_descriptors()::descriptors, which is a
> list of plugin descriptors for all the plugins in that plugin library.
> If liblv2-plugin is shared that symbol would be shared by all plugin
> libraries that a host has loaded, which would cause two problems:
>
> 1) Since all the plugin descriptors would end up in the same list, it
>    would appear to the host as if every plugin library contained every
>    plugin, which could possibly break things and definitely confuse
>    diagnostic tools, and
> 2) the code that accesses that list is not threadsafe, and the LV2
>    spec only guarantees that plugin discovery calls are not
>    executed simultaneously by the host for plugins in the same
>    library, so having a shared list for all libraries could
>    potentially corrupt memory.
>
> liblv2-gui.a has a similar problem.

I removed my hacks and I am building the two libraries static.

SPEC: http://oget.fedorapeople.org/review/lv2-c++-tools.spec
SRPM: http://oget.fedorapeople.org/review/lv2-c++-tools-1.0.3-2.fc12.src.rpm

Some notes:
- I removed the -fno-var-tracking-assignments hack too. gcc seems fixed now. It takes a little while to compile still. But it doesn't hang.
- There are two static (liblv2-gui.a, liblv2-plugin.a) and one shared (libpag.so) library. I didn't make a static subpackage since the contents of the .a files are not the same as the content of the .so file. Is this okay? What is your opinion?

Okay, static by design then (both libs make use of C "static" storage).

You would still need to follow the guidelines and create a virtual -static package:

  http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2

| If (and only if) a package has shared libraries which require
| static libraries to be functional, the static libraries can be
| included in the *-devel subpackage. The devel subpackage must
| have a virtual Provide for the *-static package, and packages
| dependent on it must BuildRequire the *-static package.

okay, I updated the package, and added a virtual provides.

SPEC: http://oget.fedorapeople.org/review/lv2-c++-tools.spec
SRPM: http://oget.fedorapeople.org/review/lv2-c++-tools-1.0.3-3.fc12.src.rpm

Michael, is this package under your review? We have two other packages waiting for this package. One of them is David Cornette's EQ10Q package. He needs to be sponsored, but in order to do that we need to get this package in. (No obligations, I am just asking.)

I'll review this one.

Looks pretty good.  Ideally there would be man pages for lv2peg and lv2soname.  Just yesterday, someone announced an intent to package this for Debian (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581419 ) so when that is done you can grab them from there.  In the meantime, you can send an email to upstream asking them for the man pages.

That is not a blocker, so this package is
APPROVED

Sure. I just sent an email upstream. Thanks for the review.

New Package CVS Request
=======================
Package Name: lv2-c++-tools
Short Description: Support library for writing LV2 plugins in C++
Owners: oget
Branches: F-11 F-12 F-13
InitialCC:

CVS Done

lv2-c++-tools-1.0.3-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc11

lv2-c++-tools-1.0.3-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc13

lv2-c++-tools-1.0.3-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc12

lv2-c++-tools-1.0.3-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lv2-c++-tools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc11

lv2-c++-tools-1.0.3-3.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lv2-c++-tools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc13

lv2-c++-tools-1.0.3-3.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update lv2-c++-tools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lv2-c++-tools-1.0.3-3.fc12

lv2-c++-tools-1.0.3-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

lv2-c++-tools-1.0.3-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

lv2-c++-tools-1.0.3-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.