Description of problem: binutils-devel provides the header files and %{_libdir}/libbfd.so necessary for linking with -lbfd. However, %{_libdir}/libbfd.so is really a linker script that pulls in %{_libdir}/libbfd.a, which is in binutils-static. Since binutils-devel does not depend on binutils-static, this means that, even though the header files and libbfd.so are available, linking with -lbfd fails unless binutils-static is also installed. Possible solutions: move libbfd.a back into binutils-devel, or move all of the libbfd headers and the .so linker script into binutils-static. Version-Release number of selected component (if applicable): binutils-devel-2.20.51.0.2-17.fc14 How reproducible: Always Steps to Reproduce: 1. Install binutils-devel 2. Write a trivial program and try to link it with -lbfd Actual results: /usr/bin/ld: cannot find /usr/lib64/libbfd.a collect2: ld returned 1 exit status Expected results: A successful link. Additional info:
Created attachment 406005 [details] Remove libbfd.so script
Hi Jerry I think that the simplest solution is to just remove the libbfd.so script and instead have it be a symbolic link to the real shared library, just like with other packages. The uploaded patch implements this idea. I'll wait a week to see if anyone has any comments or complaints, and if not then I will check it in. Cheers Nick
The problem with that is that random other packages that link with -lbfd will then link against the shared libbfd*.so library, which unfortunately doesn't have a stable ABI, sometimes not even between different revisions of the same version (that's why -%{release} has been added to the SONAME in the past). If you allow linking anything against libbfd*.so, then suddenly any time you want to update binutils in any distro, suddenly you need to wait for all such packages to be rebuilt against the new binutils and pushed at the same time. This leads to the xulrunner/mozilla/firefox/... update nightmares. I'd think that the binutils-devel packages should be just completely moved over into binutils-static and add Provides: binutils-devel = %{version}-%{release} to binutils-static.
Hi Jakub, I'll do that if you want, but I was wondering if the BFD ABI really is still changing that much these days. My feeling is that it is quite stable now and that future changes are unlikely. What do you think ? Cheers Nick
Hi Jakub, OK - I have taken your advice and merged the binutils-devel package into the binutils-static packge. Cheers Nick
The .so being a linker script for the .a is a blatant violation of our packaging guidelines.
Re: comment 6 http://koji.fedoraproject.org/koji/rpminfo?rpmID=1958066 > * Tue Apr 20 2010 Nick Clifton <nickc> - 2.20.51.0.7-2 > - Merge binutils-devel package into binutils-static package. (BZ 576300) > Provides > 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 That is also a violation of the packaging guidelines and *would* cause bug 556040 to be reopened. The problem being that any package doing "BuildRequires: binutils-devel" would implicitly use the binutils-static package and link with the static libs.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It looks like currently, a -devel package exists with a virtual provide for the static library. This seems to be following the guideline for a package which provides static libraries only: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2 which seems to be the intent of the package. Can this be closed?
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping