[Fedora-packaging] binutils once more

Toshio Kuratomi a.badger at gmail.com
Fri Jun 4 17:08:51 UTC 2010


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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20100604/52e489b6/attachment.bin 


More information about the packaging mailing list