On Fri, Jun 04, 2010 at 10:22:05AM +0200, Michael Schwendt wrote: > The saga "binutils does not adhere to Static Library Packaging Guidelines" > continues. > > Temporarily the issue had been fixed, then it has been reverted by adding > "Provides" that violate the guidelines again. When I permitted my checker > script to reopen the bugzilla ticket, it was quickly closed as NOTABUG > this time. > > binutils : does not adhere to Static Library Packaging Guidelines > https://bugzilla.redhat.com/show_bug.cgi?id=556040 > > The ticket that lead to violating the guidelines again: > > libbfd.so in binutils-devel needs libbfd.a in binutils-static > https://bugzilla.redhat.com/show_bug.cgi?id=576300 > > [...] > > I'd appreciate if the Fedora Packaging Committee discussed this and either > officially excludes the binutils package from the guidelines or adjusts the > guidelines. > > To brief all readers: binutils ships shared *and* static libs, but it > replaces the *.so files used for linking at build-time with ld scripts > that only link statically. It has been said that the library interfaces > are not stable enough to link shared. > > $ rpmlsv -p binutils-2.20.51.0.7-3.fc14.i686.rpm | grep /lib > -rwxr-xr-x root root 881172 /usr/lib/libbfd-2.20.51.0.7-3.fc14.so > -rwxr-xr-x root root 561296 /usr/lib/libopcodes-2.20.51.0.7-3.fc14.so > > $ rpmlsv -p binutils-static-2.20.51.0.7-3.fc14.i686.rpm|grep /lib > -rw-r--r-- root root 23878 /usr/include/libiberty.h > -rw-r--r-- root root 1104328 /usr/lib/libbfd.a > -rw-r--r-- root root 271 /usr/lib/libbfd.so > -rw-r--r-- root root 274322 /usr/lib/libiberty.a > -rw-r--r-- root root 589216 /usr/lib/libopcodes.a > -rw-r--r-- root root 202 /usr/lib/libopcodes.so > > $ cat libbfd.so > /* GNU ld script */ > > /* Ensure this .so library will not be used by a link for a different format > on a multi-architecture system. */ > OUTPUT_FORMAT(elf32-i386) > > /* The libz dependency is unexpected by legacy build scripts. */ > INPUT ( /usr/lib/libbfd.a -liberty -lz ) > > $ rpm -qp --provides binutils-static-2.20.51.0.7-3.fc14.i686.rpm > binutils-devel = 2.20.51.0.7-3.fc14 > binutils-static = 2.20.51.0.7-3.fc14 > binutils-static(x86-32) = 2.20.51.0.7-3.fc14 > Jakub, if you aren't on this list I can ask questions on the bug report instead. Let me know. Here's the things I need to know/confirm to draft a sensible exception into the policy: * What's the advantage to shipping shared libraries for binutils if we don't want people to link against them? (I'm guessing it has something to do with the number of utilities within the binutils package that can then link against the shared libraries but I don't know specifically what?) * Who needs to link against the binutils libraries? From mschwendt's repoquery run it looks like this:: $ repoquery --disablerepo='*' --enablerepo='rawhide-source' --srpm --whatrequires binutils-devel --qf '%{name}'|sort|uniq alleyoop avarice CodeAnalyst-gui eclipse-oprofile gcl kdesdk kernel ksplice latrace libdwarf lush mutrace oprofile pfmon sblim-wbemcli stapitrace sysprof * Is there a reason not to treat the shared libraries as internal libraries, install them to a subdirectory (%{_libdir/binutils/), use rpath in the binutils utilities themselves, have the other packages link to the static libraries in %{_libdir}, and not ship a linker script? * Is there any other technical ideas to consider? Linking the utilities in binutils statically against their libraries, etc? -Toshio
Attachment:
pgpFA6AjeIEvY.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
