Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=537363 --- Comment #2 from Orcan 'oget' Ogetbil <oget.fedora@xxxxxxxxx> 2009-12-05 16:46:40 EDT --- (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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review