Bugzilla – Bug 1141913
libbfd link problem
Last modified: 2021-03-02 14:29:39 UTC
Consider the following program: #include <bfd.h> int main(void) { bfd_close(0); return 0; } Compilation results: $ gcc -Wall -lbfd bfdtest.c /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/ccN0TVRu.o: in function `main': bfdtest.c:(.text+0xa): undefined reference to `bfd_close' collect2: error: ld returned 1 exit status $ $ gcc -Wall -lbfd-2.32 bfdtest.c $ Is there a missing link in the latest RPM package? I can no longer find libbfd.so in my system.
We only ship a static library and that's in binutils-devel.
$ rpm -qf /usr/lib64/libbfd-2.32.so binutils-2.32-5.6.x86_64 $ file /usr/lib64/libbfd-2.32.so /usr/lib64/libbfd-2.32.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c1775c8e3e85e3504798bc2a168c5c1d983c48b8, stripped This looks like a dynamic library and is shipped on binutils. My software was linking ok on Sunday, stopped linking on Monday after a "zypper dup" on Tumbleweed, I have not touched the code. Any ideas why? Seems to me that without /usr/lib64/libbfd.so I have no chance of making this work.
I have no idea why it should have ever worked. We never shipped a libbfd.so (i.e. the .so link without any versioning info), and we did so by intention. The installed libbfd shared library is only for consumption by the binutils binaries (like ld and as), not for link editing against. Normally that would have been implemented by only installing files named like libbfd.so.1.2.3, alas for binutils that's historically different. So, if your linking against -lbfd ever worked, that means you had libbfd.a installed for some reason, or something had created a libbfd.so softlink. But the latter shouldn't have been any opensuse packages. In any case, the effects you see are by intention, you're not supposed to link against the shared libbfd; if anything link against the static archive, i.e. install binutils-devel. (Though in reality, we consider removing even that possibility, libbfd doesn't care for API compatibility, and hence even providing a user-consumable library is questionable. The intended modus operandi for writing tools using libbfd is that they internally include the sources of the libbfd variant that they are tested against. That's of course not ideal, but it is what the binutils project intends.)
I understand that the following is beyond the scope of this void bug report, so, I won't be sad if no one answers. Still, it looks like something in the binutils rpms have changed. Indeed, although not obvious in the build of the project I am working, the actual linking was static, so you are totally correct, there has never been a link to a shared libbfd.so. So I got an old version of binutils, binutils-2.26.1-11.1.x86_64.rpm, and opened it in a local directory: $ nm libbfd.a | grep "T bfd_close" 0000000000000b20 T bfd_close 0000000000000c10 T bfd_close_all_done Looks ok. Then I did the same with the one currently installed in my system: $ rpm -qf /usr/lib64/libbfd.a binutils-devel-2.32-5.6.x86_64 $ nm /usr/lib64/libbfd.a | grep "T bfd_close" nm: archive.o: plugin needed to handle lto object nm: archures.o: plugin needed to handle lto object nm: bfd.o: plugin needed to handle lto object nm: bfdio.o: plugin needed to handle lto object nm: bfdwin.o: plugin needed to handle lto object ... lots of other "nm: xxxxxxx.o: plugin needed to handle lto object" Also, it seems like I am no longer able to statically against the current libbfd.a: # Local copy, notice -L. $ gcc -Wall bfdtest.c -L. -l:libbfd.a -l:libiberty.a -l:libopcodes.a -ldl -lz $ # Current system library, no -L. $ gcc -Wall bfdtest.c -l:libbfd.a -l:libiberty.a -l:libopcodes.a -ldl -lz /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: /tmp/cc4hn8Xo.o: in function `main': bfdtest.c:(.text+0xa): undefined reference to `bfd_close' collect2: error: ld returned 1 exit status Any help would be appreciated, thank you for your attention.
Huh, looks like LTO bytecode leaked there. Martin, I thought we have rpmlint checks in place that make sure this doesn't happen? To reporter - do you have 'gcc' installed? Your system _should_ have the plugin installed and thus you should get an LTO link here (not really intended by us, but ...). It should be a symlink in /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing actual shared library.
(In reply to Richard Biener from comment #5) > Huh, looks like LTO bytecode leaked there. Martin, I thought we have > rpmlint checks in place that make sure this doesn't happen? > > To reporter - do you have 'gcc' installed? Your system _should_ have > the plugin installed and thus you should get an LTO link here (not > really intended by us, but ...). It should be a symlink in > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing > actual shared library. All the examples I showed were using gcc. Maybe I have "an excess of gcc installed". Don't ask me why, I just "zypper dup" my system from time to time: $ find /usr/lib64 -name liblto_plugin.so /usr/lib64/gcc/x86_64-suse-linux/8/liblto_plugin.so /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so $ $ ls -l /usr/lib64/gcc/x86_64-suse-linux/*/liblto_plugin.so lrwxrwxrwx 1 root root 22 jul 9 12:48 /usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so -> liblto_plugin.so.0.0.0 lrwxrwxrwx 1 root root 22 jul 9 10:37 /usr/lib64/gcc/x86_64-suse-linux/8/liblto_plugin.so -> liblto_plugin.so.0.0.0 lrwxrwxrwx 1 root root 22 jul 16 08:20 /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so -> liblto_plugin.so.0.0.0 Regards, Marcelo.
Maybe it's helpful reporting that binutils 2.23-5.4 didn't have this issue so this issue is less than two minor old. I've been using those two rpms and they both have no lto issue and link as expected: http://download.opensuse.org/history/20190701/tumbleweed/repo/oss/x86_64/binutils-2.32-5.4.x86_64.rpm http://download.opensuse.org/history/20190701/tumbleweed/repo/oss/x86_64/binutils-devel-2.32-5.4.x86_64.rpm Thanks for helping us out
(In reply to Richard Biener from comment #5) > Huh, looks like LTO bytecode leaked there. Martin, I thought we have > rpmlint checks in place that make sure this doesn't happen? We do have a rpmlint check. But unfortunately, I also want to strip all LTO ELF sections in brp-check-suse that runs before the rpmlint. > > To reporter - do you have 'gcc' installed? Your system _should_ have > the plugin installed and thus you should get an LTO link here (not > really intended by us, but ...). It should be a symlink in > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing > actual shared library.
(In reply to Martin Liška from comment #8) > (In reply to Richard Biener from comment #5) > > Huh, looks like LTO bytecode leaked there. Martin, I thought we have > > rpmlint checks in place that make sure this doesn't happen? > > We do have a rpmlint check. But unfortunately, I also want to strip all LTO > ELF sections in brp-check-suse that runs before the rpmlint. Hmm, I don't see either firing and the issue in binutils is probably that the static libraries we ship are built with slim LTO so stripping the LTO bytecode wouldn't help. That is, this is a binutils packaging issue that surprisingly isn't caught by rpmlint checking that is in place? > > > > To reporter - do you have 'gcc' installed? Your system _should_ have > > the plugin installed and thus you should get an LTO link here (not > > really intended by us, but ...). It should be a symlink in > > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing > > actual shared library.
(In reply to Richard Biener from comment #9) > (In reply to Martin Liška from comment #8) > > (In reply to Richard Biener from comment #5) > > > Huh, looks like LTO bytecode leaked there. Martin, I thought we have > > > rpmlint checks in place that make sure this doesn't happen? > > > > We do have a rpmlint check. But unfortunately, I also want to strip all LTO > > ELF sections in brp-check-suse that runs before the rpmlint. > > Hmm, I don't see either firing and the issue in binutils is probably that > the static libraries we ship are built with slim LTO so stripping the LTO > bytecode wouldn't help. Exactly. Fat LTO objects will be needed for the package. > > That is, this is a binutils packaging issue that surprisingly isn't caught > by rpmlint checking that is in place? Yes, as explained, caused by LTO section stripping before the check is fired. So I'm suggesting to extend the rpmlint check to seek for __gnu_lto_slim symbol in the archive. Or do you have a better idea? Maybe an empty .text segment for embedded object files? > > > > > > > To reporter - do you have 'gcc' installed? Your system _should_ have > > > the plugin installed and thus you should get an LTO link here (not > > > really intended by us, but ...). It should be a symlink in > > > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing > > > actual shared library.
I've done a pull request to rpmlint: https://github.com/rpm-software-management/rpmlint/pull/218/commits
(In reply to Martin Liška from comment #10) > (In reply to Richard Biener from comment #9) > > (In reply to Martin Liška from comment #8) > > > (In reply to Richard Biener from comment #5) > > > > Huh, looks like LTO bytecode leaked there. Martin, I thought we have > > > > rpmlint checks in place that make sure this doesn't happen? > > > > > > We do have a rpmlint check. But unfortunately, I also want to strip all LTO > > > ELF sections in brp-check-suse that runs before the rpmlint. > > > > Hmm, I don't see either firing and the issue in binutils is probably that > > the static libraries we ship are built with slim LTO so stripping the LTO > > bytecode wouldn't help. > > Exactly. Fat LTO objects will be needed for the package. > > > > > That is, this is a binutils packaging issue that surprisingly isn't caught > > by rpmlint checking that is in place? > > Yes, as explained, caused by LTO section stripping before the check is > fired. So I'm suggesting to extend the rpmlint check to seek for > __gnu_lto_slim symbol in the archive. Ah, OK. I would suggest to not strip LTO sections for slim objects instead. I guess invoking ar in a way forcing not to load a plugin would reveal such? > Or do you have a better idea? Maybe an empty .text segment for embedded > object files? > > > > > > > > > > > To reporter - do you have 'gcc' installed? Your system _should_ have > > > > the plugin installed and thus you should get an LTO link here (not > > > > really intended by us, but ...). It should be a symlink in > > > > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing > > > > actual shared library.
> > Ah, OK. I would suggest to not strip LTO sections for slim objects instead. > I guess invoking ar in a way forcing not to load a plugin would reveal > such? > Interesting idea. Does ar has an option to not use the plugin and fail eventually?
This is an autogenerated message for OBS integration: This bug (1141913) was mentioned in https://build.opensuse.org/request/show/717878 Factory / binutils
SUSE-SU-2019:2650-1: An update that solves 17 vulnerabilities and has three fixes is now available. Category: security (moderate) Bug References: 1109412,1109413,1109414,1111996,1112534,1112535,1113247,1113252,1113255,1116827,1118830,1118831,1120640,1121034,1121035,1121056,1133131,1133232,1141913,1142772 CVE References: CVE-2018-1000876,CVE-2018-17358,CVE-2018-17359,CVE-2018-17360,CVE-2018-17985,CVE-2018-18309,CVE-2018-18483,CVE-2018-18484,CVE-2018-18605,CVE-2018-18606,CVE-2018-18607,CVE-2018-19931,CVE-2018-19932,CVE-2018-20623,CVE-2018-20651,CVE-2018-20671,CVE-2019-1010180 Sources used: SUSE OpenStack Cloud Crowbar 8 (src): binutils-2.32-9.33.1 SUSE OpenStack Cloud 8 (src): binutils-2.32-9.33.1 SUSE OpenStack Cloud 7 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Software Development Kit 12-SP5 (src): binutils-2.32-9.33.1, cross-ppc-binutils-2.32-9.33.1, cross-spu-binutils-2.32-9.33.1 SUSE Linux Enterprise Software Development Kit 12-SP4 (src): binutils-2.32-9.33.1, cross-ppc-binutils-2.32-9.33.1, cross-spu-binutils-2.32-9.33.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server for SAP 12-SP2 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server for SAP 12-SP1 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP5 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP4 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP2-LTSS (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP2-BCL (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Server 12-SP1-LTSS (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Desktop 12-SP5 (src): binutils-2.32-9.33.1 SUSE Linux Enterprise Desktop 12-SP4 (src): binutils-2.32-9.33.1 SUSE Enterprise Storage 5 (src): binutils-2.32-9.33.1 SUSE Enterprise Storage 4 (src): binutils-2.32-9.33.1 HPE Helion Openstack 8 (src): binutils-2.32-9.33.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2019:2779-1: An update that fixes 28 vulnerabilities is now available. Category: security (moderate) Bug References: 1109412,1109413,1109414,1111996,1112534,1112535,1113247,1113252,1113255,1116827,1118644,1118830,1118831,1120640,1121034,1121035,1121056,1133131,1133232,1141913,1142772,1152590,1154016,1154025 CVE References: CVE-2018-1000876,CVE-2018-17358,CVE-2018-17359,CVE-2018-17360,CVE-2018-17985,CVE-2018-18309,CVE-2018-18483,CVE-2018-18484,CVE-2018-18605,CVE-2018-18606,CVE-2018-18607,CVE-2018-19931,CVE-2018-19932,CVE-2018-20623,CVE-2018-20651,CVE-2018-20671,CVE-2018-6323,CVE-2018-6543,CVE-2018-6759,CVE-2018-6872,CVE-2018-7208,CVE-2018-7568,CVE-2018-7569,CVE-2018-7570,CVE-2018-7642,CVE-2018-7643,CVE-2018-8945,CVE-2019-1010180 Sources used: SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP1 (src): binutils-2.32-7.5.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): binutils-2.32-7.5.1, cross-aarch64-binutils-2.32-7.5.1, cross-arm-binutils-2.32-7.5.1, cross-avr-binutils-2.32-7.5.1, cross-epiphany-binutils-2.32-7.5.1, cross-hppa-binutils-2.32-7.5.1, cross-hppa64-binutils-2.32-7.5.1, cross-i386-binutils-2.32-7.5.1, cross-ia64-binutils-2.32-7.5.1, cross-m68k-binutils-2.32-7.5.1, cross-mips-binutils-2.32-7.5.1, cross-ppc-binutils-2.32-7.5.1, cross-ppc64-binutils-2.32-7.5.1, cross-ppc64le-binutils-2.32-7.5.1, cross-riscv64-binutils-2.32-7.5.1, cross-rx-binutils-2.32-7.5.1, cross-s390-binutils-2.32-7.5.1, cross-s390x-binutils-2.32-7.5.1, cross-sparc-binutils-2.32-7.5.1, cross-sparc64-binutils-2.32-7.5.1, cross-spu-binutils-2.32-7.5.1, cross-x86_64-binutils-2.32-7.5.1 SUSE Linux Enterprise Module for Development Tools 15-SP1 (src): binutils-2.32-7.5.1 SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): binutils-2.32-7.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2019:2780-1: An update that fixes 28 vulnerabilities is now available. Category: security (moderate) Bug References: 1109412,1109413,1109414,1111996,1112534,1112535,1113247,1113252,1113255,1116827,1118644,1118830,1118831,1120640,1121034,1121035,1121056,1133131,1133232,1141913,1142772,1152590,1154016,1154025 CVE References: CVE-2018-1000876,CVE-2018-17358,CVE-2018-17359,CVE-2018-17360,CVE-2018-17985,CVE-2018-18309,CVE-2018-18483,CVE-2018-18484,CVE-2018-18605,CVE-2018-18606,CVE-2018-18607,CVE-2018-19931,CVE-2018-19932,CVE-2018-20623,CVE-2018-20651,CVE-2018-20671,CVE-2018-6323,CVE-2018-6543,CVE-2018-6759,CVE-2018-6872,CVE-2018-7208,CVE-2018-7568,CVE-2018-7569,CVE-2018-7570,CVE-2018-7642,CVE-2018-7643,CVE-2018-8945,CVE-2019-1010180 Sources used: SUSE Linux Enterprise Module for Packagehub Subpackages 15 (src): binutils-2.32-6.8.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): binutils-2.32-6.8.1, cross-arm-binutils-2.32-6.8.1, cross-avr-binutils-2.32-6.8.1, cross-epiphany-binutils-2.32-6.8.1, cross-hppa-binutils-2.32-6.8.1, cross-hppa64-binutils-2.32-6.8.1, cross-i386-binutils-2.32-6.8.1, cross-ia64-binutils-2.32-6.8.1, cross-m68k-binutils-2.32-6.8.1, cross-mips-binutils-2.32-6.8.1, cross-ppc-binutils-2.32-6.8.1, cross-ppc64-binutils-2.32-6.8.1, cross-riscv64-binutils-2.32-6.8.1, cross-rx-binutils-2.32-6.8.1, cross-s390-binutils-2.32-6.8.1, cross-sparc-binutils-2.32-6.8.1, cross-sparc64-binutils-2.32-6.8.1, cross-spu-binutils-2.32-6.8.1 SUSE Linux Enterprise Module for Development Tools 15 (src): binutils-2.32-6.8.1 SUSE Linux Enterprise Module for Basesystem 15 (src): binutils-2.32-6.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSUSE-SU-2019:2415-1: An update that fixes 28 vulnerabilities is now available. Category: security (moderate) Bug References: 1109412,1109413,1109414,1111996,1112534,1112535,1113247,1113252,1113255,1116827,1118644,1118830,1118831,1120640,1121034,1121035,1121056,1133131,1133232,1141913,1142772,1152590,1154016,1154025 CVE References: CVE-2018-1000876,CVE-2018-17358,CVE-2018-17359,CVE-2018-17360,CVE-2018-17985,CVE-2018-18309,CVE-2018-18483,CVE-2018-18484,CVE-2018-18605,CVE-2018-18606,CVE-2018-18607,CVE-2018-19931,CVE-2018-19932,CVE-2018-20623,CVE-2018-20651,CVE-2018-20671,CVE-2018-6323,CVE-2018-6543,CVE-2018-6759,CVE-2018-6872,CVE-2018-7208,CVE-2018-7568,CVE-2018-7569,CVE-2018-7570,CVE-2018-7642,CVE-2018-7643,CVE-2018-8945,CVE-2019-1010180 Sources used: openSUSE Leap 15.0 (src): binutils-2.32-lp150.10.1
openSUSE-SU-2019:2432-1: An update that fixes 28 vulnerabilities is now available. Category: security (moderate) Bug References: 1109412,1109413,1109414,1111996,1112534,1112535,1113247,1113252,1113255,1116827,1118644,1118830,1118831,1120640,1121034,1121035,1121056,1133131,1133232,1141913,1142772,1152590,1154016,1154025 CVE References: CVE-2018-1000876,CVE-2018-17358,CVE-2018-17359,CVE-2018-17360,CVE-2018-17985,CVE-2018-18309,CVE-2018-18483,CVE-2018-18484,CVE-2018-18605,CVE-2018-18606,CVE-2018-18607,CVE-2018-19931,CVE-2018-19932,CVE-2018-20623,CVE-2018-20651,CVE-2018-20671,CVE-2018-6323,CVE-2018-6543,CVE-2018-6759,CVE-2018-6872,CVE-2018-7208,CVE-2018-7568,CVE-2018-7569,CVE-2018-7570,CVE-2018-7642,CVE-2018-7643,CVE-2018-8945,CVE-2019-1010180 Sources used: openSUSE Leap 15.1 (src): binutils-2.32-lp151.3.3.1, cross-aarch64-binutils-2.32-lp151.3.3.1, cross-arm-binutils-2.32-lp151.3.3.1, cross-avr-binutils-2.32-lp151.3.3.1, cross-epiphany-binutils-2.32-lp151.3.3.1, cross-hppa-binutils-2.32-lp151.3.3.1, cross-hppa64-binutils-2.32-lp151.3.3.1, cross-i386-binutils-2.32-lp151.3.3.1, cross-ia64-binutils-2.32-lp151.3.3.1, cross-m68k-binutils-2.32-lp151.3.3.1, cross-mips-binutils-2.32-lp151.3.3.1, cross-ppc-binutils-2.32-lp151.3.3.1, cross-ppc64-binutils-2.32-lp151.3.3.1, cross-ppc64le-binutils-2.32-lp151.3.3.1, cross-riscv64-binutils-2.32-lp151.3.3.1, cross-rx-binutils-2.32-lp151.3.3.1, cross-s390-binutils-2.32-lp151.3.3.1, cross-s390x-binutils-2.32-lp151.3.3.1, cross-sparc-binutils-2.32-lp151.3.3.1, cross-sparc64-binutils-2.32-lp151.3.3.1, cross-spu-binutils-2.32-lp151.3.3.1
Should be fixed now.