Bug 1141913 - libbfd link problem
libbfd link problem
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 All
: P5 - None : Normal (vote)
: ---
Assigned To: Martin Liška
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-17 21:34 UTC by Marcelo Jimenez
Modified: 2021-03-02 14:29 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcelo Jimenez 2019-07-17 21:34:04 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.
Comment 1 Richard Biener 2019-07-18 07:43:26 UTC
We only ship a static library and that's in binutils-devel.
Comment 2 Marcelo Jimenez 2019-07-18 13:26:58 UTC
$ 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.
Comment 3 Michael Matz 2019-07-18 13:44:19 UTC
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.)
Comment 4 Marcelo Jimenez 2019-07-18 20:35:39 UTC
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.
Comment 5 Richard Biener 2019-07-19 08:53:52 UTC
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.
Comment 6 Marcelo Jimenez 2019-07-19 13:34:00 UTC
(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.
Comment 7 Raphael Bertoche 2019-07-20 01:34:08 UTC
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
Comment 8 Martin Liška 2019-07-22 07:00:29 UTC
(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.
Comment 9 Richard Biener 2019-07-22 07:26:03 UTC
(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.
Comment 10 Martin Liška 2019-07-22 09:51:09 UTC
(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.
Comment 11 Martin Liška 2019-07-22 10:36:26 UTC
I've done a pull request to rpmlint:
https://github.com/rpm-software-management/rpmlint/pull/218/commits
Comment 12 Richard Biener 2019-07-22 10:44:15 UTC
(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.
Comment 13 Martin Liška 2019-07-22 10:48:55 UTC
> 
> 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?
Comment 14 Swamp Workflow Management 2019-07-23 12:40:06 UTC
This is an autogenerated message for OBS integration:
This bug (1141913) was mentioned in
https://build.opensuse.org/request/show/717878 Factory / binutils
Comment 17 Swamp Workflow Management 2019-10-14 13:13:26 UTC
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.
Comment 19 Swamp Workflow Management 2019-10-24 19:14:06 UTC
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.
Comment 20 Swamp Workflow Management 2019-10-25 16:15:31 UTC
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.
Comment 21 Swamp Workflow Management 2019-10-30 23:16:43 UTC
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
Comment 22 Swamp Workflow Management 2019-11-05 20:20:51 UTC
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
Comment 23 Martin Liška 2021-03-02 14:29:39 UTC
Should be fixed now.