Bug 556040

The binutils API is considered to be too unstable for dynamic use.  Hence most packages that use the BFD or OPCODES libraries will require the static libraries.

Please follow the guidelines.

They don't make any sense for binutils.

Jakub,

could you please provide any explanation to why the static libraries couldn't be split into a -static subpackage to conform, like any other package, to the current guidelines?

Thanks

Because the -devel subpackage, which would provide libbfd.so/libopcodes.so would necessarily need to Requires: binutils-static, as libbfd.so/libopcodes.so are linker scripts that include libbfd.a resp. libopcodes.a together with libraries they need.
So, while it is technically possible to split it, it wouldn't just cause bloat and wouldn't do any good.

Nebulous. Are you trying to say that libbfd.so/libopcodes.so are ld scripts and can only be used to link statically? If so, they belong into a binutils-static package despite their .so file extension.

Or else this would be static linking in disguise, which would violate the guidelines and the goal of being able to track builds that explicitly want to link statically.

Still reproducible. Reopened by: fedora-report-static-batch.py

binutils-devel
    /usr/lib/libbfd.so  <=>  /usr/lib/libbfd.a
    /usr/lib/libopcodes.so  <=>  /usr/lib/libopcodes.a

Hi Michael,

  Would you care to try out the binutils-2_20_51_0_2-15-fc13 rpm in rawhide ?  I have split off the static libraries into a separate binutils-static package as per the Packing Guidelines, although I am not sure how many other packages this is going to break.

Cheers
  Nick

Well, if you would like me to test something instead of relying on a tool to close/reopen this ticket, how about a reply to comment 6?

$ rpmls -p binutils-devel-2.20.51.0.2-15.fc13.i686.rpm|grep so
-rw-r--r--  /usr/lib/libbfd.so
-rw-r--r--  /usr/lib/libopcodes.so

These are customised for linking statically, so why not move them into the -static package as well?

[...]

The list of src.rpm packages, which directly "BuildRequires: binutils-devel", is 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

The list of packages, which refer to -lbfd or -lopcodes somewhere in their build.log, is this:

avarice
CodeAnalyst-gui
eclipse-oprofile
gcl
ksplice
lush
mutrace
oprofile
stapitrace

They certainly need to add "BuildRequires: binutils-static" in accordance with the guidelines.

As whether the remaining packages really need to BR binutils-devel, e.g. for just the headers, or whether perhaps their build.log is too quiet, remains to be examined.

Closed by: fedora-report-static-batch.py

Still reproducible. Reopened by: fedora-report-static-batch.py

Build: binutils-2.20.51.0.7-3.fc14.src.rpm

binutils-static
    /usr/lib/libbfd.so  <=>  /usr/lib/libbfd.a
    /usr/lib/libopcodes.so  <=>  /usr/lib/libopcodes.a

Reopened by: fedora-report-static-batch.py

Build: binutils-2.20.51.0.7-4.fc14.src.rpm

binutils-static
    /usr/lib/libbfd.so  <=>  /usr/lib/libbfd.a
    /usr/lib/libopcodes.so  <=>  /usr/lib/libopcodes.a

It is not a bug, fix your script.

Reopened by: fedora-report-static-batch.py

Build: binutils-2.20.51.0.7-4.fc14.src.rpm

binutils-static
    (!) PROVIDES binutils-devel
    /usr/lib/libbfd.so  <=>  /usr/lib/libbfd.a
    /usr/lib/libopcodes.so  <=>  /usr/lib/libopcodes.a

Closed by: fedora-report-static-batch.py