#405 Request to find resolution for the binutils static library saga
Closed None Opened 13 years ago by mschwendt.

With this request, I'm following Jesse Keating's suggestion (from February on the packaging mailing list) to bring this issue to FESCo's attention.

--

Please decide on whether the "binutils" package builds adhere to Fedora's Static Library Packaging Guidelines, or grant the package an exception, so it doesn't need to follow the guidelines.

http://mschwendt.fedorapeople.org/staticbugstat.html
-> http://bugzilla.redhat.com/556040

--

Originally, source RPM package "binutils" had built shared and static libraries and placed them in the "binutils-devel" package. That has lead to filing http://bugzilla.redhat.com/556040 (binutils : does not adhere to Static Library Packaging Guidelines) using a tool that examines Rawhide and is able to open/close tickets automatically.

Eventually, albeit only after some resistance, the static libraries had been split off into a binutils-static package, closing the bugzilla ticket.

The remaining files in binutils-devel, however, cannot be used to link shared. The *.so symlinks are replaced with GNU ld scripts that enforce linking statically. So, while the split between binutils-devel and binutils-static adhered to the guidelines, any package with "BuildRequires: binutils-devel" could not link with binutils' libraries at all unless it also added "BuildRequires: binutils-static". There is a little bit more than a dozen of src.rpms that depend on binutils-devel. And only binutils itself links with its own shared libs.

Weeks later, somebody discovered that "libbfd.so in binutils-devel needs libbfd.a in binutils-static" - http://bugzilla.redhat.com/576300 - and instead of using "BuildRequires: binutils-static" to get access to the needed lib, the binutils packaging was modified again.

Now, binutils-static includes both the static libs and the *.so ld scripts again and additionally provides a virtual "binutils-devel" package. This is a violation of the packaging guidelines once more, because the static libs and static linkage are implicitly enabled for any package that "BuildRequires: binutils-devel".


Adding meeting keyword for next meeting.

See also fesco ticket 370.

Leaving some comments here since I am going to miss the fesco meeting, probably:

  1. Shipping linker as .so files seems just deceptive.

  2. It appears that upstream binutils (which is the same as our package maintainers ?) just doesn't want to allow dynamic linking against libbfd.so. If that is the case they should just not ship .so s, imo, and just make -devel provide -static, as allowed by the packaging guidelines.

Notting is going to talk to the binutils maintainer and see if they can't just rename -static to -devel, adjust provides accordingly to bring it in line with guidelines.

Will leave this open for implementation.

Whether the pkg is called -devel with a virtual -static pkg, or whether it is called -static with a virtual -devel pkg (the current situation), doesn't make a difference. To ask for renaming is splitting-hairs.

All that matters is whether FESCo thinks that shipping shared libs and static libs and enforcing static linking "under the hood" is still meeting the guidelines.

Yes, we do. (That was certainly my read of the consensus during the meeting anyway.)

From Nick C:

{{{
Hi Roland, Hi Bill,

Seems like a trivial change.

Agreed. I have checked in your patch along with a rewording of the
description for the binutils-devel package which I hope makes the
situation clearer.

Cheers
Nick
}}}

Closing.

Thanks, everyone!

Bz tickets have been opened for all packages that link with binutils' static libraries according the koji build.log output. Those need to "BuildRequires: binutils-static".

Login to comment on this ticket.

Metadata