Bug 834720 – sys-devel/binutils-2.37_p1-r2 - lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a' generated with LTO version 11.0 instead of the expected 11.2

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description ernsteiswuerfel 2022-03-07 14:51:59 UTC]

Created attachment 766475 [details]
build.log (amd64)

Since upgrading to sys-devel/gcc-11.2.1_p20220115 building sys-devel/binutils-2.37_p1-r2 fails:

[...]
libtool: install: (cd /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/libctf; /bin/sh /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/libctf/libtool  --tag CC --mode=relink x86_64-pc-linux-gnu-gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -O2 -march=btver1 -mtune=btver1 -pipe -release 2.37.gentoo-sys-devel-binutils-st -Wl,--version-script=/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/libctf/libctf.ver -Wl,-O1 -Wl,--as-needed -o libctf.la -rpath /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-open-bfd.lo ../bfd/libbfd.la -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/libctf/../libiberty/pic -liberty -lz -ldl -inst-prefix-dir /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image)
libtool: relink: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC  .libs/libctf_la-ctf-archive.o .libs/libctf_la-ctf-dump.o .libs/libctf_la-ctf-create.o .libs/libctf_la-ctf-decl.o .libs/libctf_la-ctf-error.o .libs/libctf_la-ctf-hash.o .libs/libctf_la-ctf-labels.o .libs/libctf_la-ctf-dedup.o .libs/libctf_la-ctf-link.o .libs/libctf_la-ctf-lookup.o .libs/libctf_la-ctf-open.o .libs/libctf_la-ctf-serialize.o .libs/libctf_la-ctf-sha1.o .libs/libctf_la-ctf-string.o .libs/libctf_la-ctf-subr.o .libs/libctf_la-ctf-types.o .libs/libctf_la-ctf-util.o .libs/libctf_la-ctf-open-bfd.o   -Wl,-rpath -Wl,/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 -Wl,--as-needed -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 -lbfd -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/bfd/../libiberty/pic -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/libctf/../libiberty/pic -liberty -lz -ldl  -march=btver1 -mtune=btver1 -Wl,--version-script=/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/libctf/libctf.ver -Wl,-O1   -Wl,-soname -Wl,libctf-2.37.gentoo-sys-devel-binutils-st.so -o .libs/libctf-2.37.gentoo-sys-devel-binutils-st.so
lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a' generated with LTO version 11.0 instead of the expected 11.2
compilation terminated.
lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libctf.la' with the above command before installing it
make[3]: *** [Makefile:568: install-libLTLIBRARIES] Error 1


Doesn't matter whether building with USE pgo or -pgo. And it's not arch specific, I get the same failure on ppc64. ;)

gcc was built with:
[ebuild   R    ] sys-devel/gcc-11.2.1_p20220115:11::gentoo  USE="(cxx) fortran (multilib) nptl objc openmp (pie) sanitize ssp zstd (-ada) (-cet) -custom-cflags -d -debug -doc (-fixed-point) -go -graphite (-hardened) -jit (-libssp) -lto -nls -objc++ -objc-gc (-pch) -pgo -systemtap -test -valgrind -vanilla -vtv" 0 KiB

Temporary workaround is using sys-devel/binutils-2.38 ** which builds fine.

[Comment 1 ernsteiswuerfel 2022-03-07 14:52:31 UTC]

Created attachment 766476 [details]
emerge --info

[Comment 2 ernsteiswuerfel 2022-03-08 00:45:40 UTC]

Discovered a 2nd workaround (besides binutils-2.38): Building binutils-2.37_p1-r2 with clang and afterwards with gcc again works too.

[Comment 3 Sam James 2022-03-08 12:53:35 UTC]

I'm fairly sure that this is going to be a bug in our patch to build the libraries with SONAMEs -- it looks like it's trying to use the system copy of the library and not the one just built.

[Comment 4 Sam James 2022-03-09 01:23:51 UTC]

(In reply to Sam James from comment #3)
> I'm fairly sure that this is going to be a bug in our patch to build the
> libraries with SONAMEs -- it looks like it's trying to use the system copy
> of the library and not the one just built.

Does USE=vanilla help? (Don't keep running with it afterwards, maybe quickpkg beforehand.)

[Comment 5 ernsteiswuerfel 2022-03-09 13:04:22 UTC]

(In reply to Sam James from comment #4)
> Does USE=vanilla help? (Don't keep running with it afterwards, maybe
> quickpkg beforehand.)
Does not seem to make a difference. Tried on my x86 box which is still affected.

On my amd64 boxes and the Talos II I already used the "CC=clang workaround" and after that binutils-2.37_p1-r2 builds find again with gcc.

[Comment 6 ernsteiswuerfel 2022-03-09 13:05:10 UTC]

Created attachment 766638 [details]
build.log (x86, USE=vanilla)

[Comment 7 m1027 2022-03-30 15:49:06 UTC]

FYI: I had the same issue and worked around it as follows. Probably not every
step is required but I haven't investigated it further.

(1) I disabled my lto setup in make.conf for binutils-libs and binutils via
package.env. I tried to recompile both, binutils still failed.

(2) Tried recompiling binutils with USE="-pgo". No success.

(3) Then I used libiberty.a from binutils-libs:

> $ equery b libiberty.a
>  * Searching for libiberty.a ...
> sys-devel/binutils-2.37_p1-r2 (/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a)
> sys-libs/binutils-libs-2.37_p1-r2 (/usr/lib64/libiberty.a)

I copied libiberty.a from binutils-libs over the binutils version.

(4) Recompiling binutils went through!

(5) I reenabled lto via make.conf as well as +pgo in the USE flags and recompiled
binutils-libs and binutils. Recompiling went through again.

[Comment 8 ernsteiswuerfel 2022-04-23 12:36:14 UTC]

(In reply to m1027 from comment #7)
> FYI: I had the same issue and worked around it as follows. Probably not every
> step is required but I haven't investigated it further.
Thanks for sharing your workaround! It's much less cumbersome as mine. ;)

Steps 3 + 4 are sufficient. I don't use a special lto build though.

[Comment 9 Andreas K. Hüttel 2022-05-01 02:21:05 UTC]

From the log, how I understand the error is:

it needs to use the newly built libiberty.a one, but it picks up the installed libiberty.a first -> mismatch

so the trick will be to analyse library search paths and makefile rules, fun...

[Comment 10 Francisco Blas Izquierdo Riera (RETIRED) 2022-06-05 23:06:25 UTC]

For others who, like me, find this bug using google this is the solution that worked for me:
# emerge -v1a binutils-libs
# CC="clang" USE="-lto -plugins -gold -pgo" emerge -v1a --nodeps binutils
# . /etc/profile
# emerge -v1a binutils
# . /etc/profile
# emerge -v1a binutils-libs

Using clang disables lto (which requires disabling plugins which llvm's gold use requires). Nevertheless, this generates a version of binutils that seems to compile itself correctly afterwards.

[Comment 11 Andreas K. Hüttel 2022-06-06 18:04:34 UTC]

(In reply to ernsteiswuerfel from comment #5)
> (In reply to Sam James from comment #4)
> > Does USE=vanilla help? (Don't keep running with it afterwards, maybe
> > quickpkg beforehand.)
> Does not seem to make a difference. Tried on my x86 box which is still
> affected.
> 
> On my amd64 boxes and the Talos II I already used the "CC=clang workaround"
> and after that binutils-2.37_p1-r2 builds find again with gcc.

Unsurprising, since for 2.37_p1 the patch base is already a Gentoo-specific tarball (USE=vanilla here switches off only the patches on top of _p1).

[Comment 12 Andreas K. Hüttel 2022-06-06 18:09:44 UTC]

(In reply to ernsteiswuerfel from comment #1)
> Created attachment 766476 [details]
> emerge --info

ernsteiswürfel: Do I see this correctly that you have enabled LTO nowhere (not in USE, not in *FLAGS) and STILL get an LTO-related error message???

[Comment 13 LABBE Corentin 2022-06-07 14:14:56 UTC]

My gcc was built with lto and I get this error message.

[Comment 14 ernsteiswuerfel 2022-06-07 21:31:10 UTC]

(In reply to Andreas K. Hüttel from comment #12)
> ernsteiswürfel: Do I see this correctly that you have enabled LTO nowhere
> (not in USE, not in *FLAGS) and STILL get an LTO-related error message???
Yes, that was the case at the time I posted the bug. But meanwhile I used the workaround to upgrade all my systems so I can no longer reproduce the original issue.

[Comment 15 Andreas K. Hüttel 2022-06-11 16:38:50 UTC]

(In reply to LABBE Corentin from comment #13)
> My gcc was built with lto and I get this error message.

Thanks. I'm still working on reproducing this issue locally.

[Comment 16 Andreas K. Hüttel 2022-06-11 22:00:16 UTC]

(In reply to Andreas K. Hüttel from comment #15)
> (In reply to LABBE Corentin from comment #13)
> > My gcc was built with lto and I get this error message.
> 
> Thanks. I'm still working on reproducing this issue locally.

Ionen figured the reproducer out:

# the catch was that /previous/ binutils needs USE=pgo, or else
# libiberty.a is not built with lto to trigger the failure
#
# flags may not matter but was trying with for better chances
export C{,XX}FLAGS="-march=native -O2 -flto"
export USE=pgo
eselect gcc set x86_64-pc-linux-gnu-12.1.1
emerge -1 sys-devel/binutils:2.37
eselect binutils set x86_64-pc-linux-gnu-2.37_p1

USE=-pgo
eselect gcc set x86_64-pc-linux-gnu-11.3.0
emerge -1 sys-devel/binutils:2.37 # fails

[Comment 17 Andreas K. Hüttel 2022-06-11 22:05:18 UTC]

While the symptoms and the trigger are different, the underlying problem here is similar to bug 838925: relinking at install time picks up the wrong library due to the changed tooldir setting.

(mostly as note to self) This is the comment left by slyfox in the ebuild:

# Note [tooldir hack for ldscripts]
# ---------------------------------
# Build system does not allow ./configure to tweak every location
# we need for slotting binutils hence all the shuffling in
# src_install(). This note is about SCRIPTDIR define handling.
#
# SCRIPTDIR defines 'ldscripts/' directory location. SCRIPTDIR value
# is set at build-time in ld/Makefile.am as: 'scriptdir = $(tooldir)/lib'
# and hardcoded as -DSCRIPTDIR='"$(scriptdir)"' at compile time.
# Thus we can't just move files around after compilation finished.
#
# Our goal is the following:
# - at build-time set scriptdir to point to symlinked location:
#   ${TOOLPATH}: /usr/${CHOST} (or /usr/${CHOST}/${CTARGET} for cross-case)
# - at install-time set scriptdir to point to slotted location:
#   ${LIBPATH}: /usr/$(get_libdir)/binutils/${CTARGET}/${PV}

[Comment 18 Andreas K. Hüttel 2022-06-11 22:57:40 UTC]

Problem introduced by

commit b023986de7d466d361798bae98f45f8ba7a42e8a (HEAD)
Author:     Sergei Trofimovich <[e-mail]>
AuthorDate: Sat Apr 7 11:40:14 2018 +0100
Commit:     Sergei Trofimovich <[e-mail]>
CommitDate: Sat Apr 7 11:42:41 2018 +0100

    sys-devel/binutils: fix ldscrips ${CTARGET} search path, bug #147155
    
    This change fixes long-standing search path issue in Gentoo's binutils:
    
    Before the change search path was the following:
        /usr/${CTARGET}/lib/ldscripts
    Note: it points to $SYSROOT, not to native cross-tools.
    
    After the change search path is the following:
        /usr/${CHOST}/${CTARGET}/lib/ldscripts
    
    Added two notes to the ebuild on how things are supposed to work:
    - Note [slotting support]
    - Note [tooldir hack for ldscripts]
    
    Applied change to 2.30-r1 and live ebuilds.
    
    Reported-by: Heiko Rosemann
    Closes: https://bugs.gentoo.org/147155
    Package-Manager: Portage-2.3.28, Repoman-2.3.9

[Comment 19 Larry the Git Cow 2022-06-12 19:46:43 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ea456d072e46530ea53f04fe8935693fab59093

commit 8ea456d072e46530ea53f04fe8935693fab59093
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2022-06-12 19:43:40 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2022-06-12 19:46:30 +0000

    sys-devel/binutils: Prevent relinking on install, try 1
    
    The tooldir hack introduced to solve bug 147155 makes libtool
    relink libraries during the installation phase. This fails in
    enough cases to be an annoyance. Use the hack only for cross
    installations.
    
    *Untested*, needs some careful observation before regaining keywords.
    
    Bug: https://bugs.gentoo.org/147155
    Bug: https://bugs.gentoo.org/834720
    Bug: https://bugs.gentoo.org/838925
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 sys-devel/binutils/binutils-2.37_p1-r3.ebuild | 476 +++++++++++++++++++++++++
 sys-devel/binutils/binutils-2.38-r3.ebuild    | 484 ++++++++++++++++++++++++++
 sys-devel/binutils/binutils-9999.ebuild       |  21 +-
 3 files changed, 978 insertions(+), 3 deletions(-)

[Comment 20 Sebastian L. 2022-06-19 17:05:00 UTC]

(In reply to Larry the Git Cow from comment #19)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=8ea456d072e46530ea53f04fe8935693fab59093
> 
> commit 8ea456d072e46530ea53f04fe8935693fab59093
> Author:     Andreas K. Hüttel <[e-mail]>
> AuthorDate: 2022-06-12 19:43:40 +0000
> Commit:     Andreas K. Hüttel <[e-mail]>
> CommitDate: 2022-06-12 19:46:30 +0000
> 
>     sys-devel/binutils: Prevent relinking on install, try 1
>     
>     The tooldir hack introduced to solve bug 147155 makes libtool
>     relink libraries during the installation phase. This fails in
>     enough cases to be an annoyance. Use the hack only for cross
>     installations.
>     
>     *Untested*, needs some careful observation before regaining keywords.
>     
>     Bug: https://bugs.gentoo.org/147155
>     Bug: https://bugs.gentoo.org/834720
>     Bug: https://bugs.gentoo.org/838925
>     Signed-off-by: Andreas K. Hüttel <[e-mail]>
> 
>  sys-devel/binutils/binutils-2.37_p1-r3.ebuild | 476
> +++++++++++++++++++++++++
>  sys-devel/binutils/binutils-2.38-r3.ebuild    | 484
> ++++++++++++++++++++++++++
>  sys-devel/binutils/binutils-9999.ebuild       |  21 +-
>  3 files changed, 978 insertions(+), 3 deletions(-)


Andreas, I ran into this issue today.
Unmasked 2.37_p1-r3, but it still referenced libiberty.a from /usr/lib64/binutils:
```
libtool: install: warning: relinking `libopcodes.la'
libtool: install: (cd /var/tmp/portage/sys-devel/binutils-2.37_p1-r3/work/build/opcodes; /bin/sh /var/tmp/portage/sys-devel/binutils-2.37_p1-r3/work/build/opcodes/libtool  --tag CC --mode=relink x86_64-pc-linux-gnu-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -march=core2 -O2 -pipe -fprofile-use -flto=jobserver -ffat-lto-objects -release 2.37.gentoo-sys-devel-binutils-st -Wl,-O1 -Wl,--as-needed -o libopcodes.la -rpath /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 dis-buf.lo disassemble.lo dis-init.lo i386-dis.lo i386-opc.lo ../bfd/libbfd.la -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r3/work/build/opcodes/../libiberty/pic -liberty -Wl,-lc,--as-needed,-lm,--no-as-needed -inst-prefix-dir /var/tmp/portage/sys-devel/binutils-2.37_p1-r3/image)
lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a' generated with LTO version 11.2 instead of the expected 11.3
```

So the -r3 probably doesn't solve the issue.

[Comment 21 Tomek L 2022-06-26 10:41:37 UTC]

I've merged 2.37_p1-r2, but it fail when trying to re-emerge it, tried to update/recompile whole system and this is single ebuild which is broken:

# emerge -eDvNt world 

if test "opcodes" = "gettext"; then \
  if test -r /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/opcodes/../mkinstalldirs; then \
    /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/opcodes/../mkinstalldirs /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/share/binutils-data/x86_64-pc-linux-gnu/2.37_p1/gettext/po; \
  else \
    /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/opcodes/mkinstalldirs /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/share/binutils-data/x86_64-pc-linux-gnu/2.37_p1/gettext/po; \
  fi; \
  /usr/lib/portage/python3.10/ebuild-helpers/xattr/install -c -m 644 /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/binutils-2.37/opcodes/po/Makefile.in.in \
		  /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/share/binutils-data/x86_64-pc-linux-gnu/2.37_p1/gettext/po/Makefile.in.in; \
else \
  : ; \
fi
make[3]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/opcodes/po'
make[2]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/opcodes'
make[1]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build'
make: *** [Makefile:2346: install] Error 2
 * ERROR: sys-devel/binutils-2.37_p1-r2::gentoo failed (install phase):

[Comment 22 Dylan 2022-07-04 15:26:56 UTC]

I am getting a similar error message, but with GCC 12.1.1:

 /bin/mkdir -p '/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1'
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libopcodes.la '/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1'
libtool: install: warning: relinking `libopcodes.la'
libtool: install: (cd /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/opcodes; /bin/sh /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/opcodes/libtool  --tag CC --mode=relink x86_64-pc-linux-gnu-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -pipe -march=native -Wl,-O1 -Wl,--as-needed -O2 -fprofile-use -flto=jobserver -ffat-lto-objects -release 2.37.gentoo-sys-devel-binutils-st -Wl,-O1 -Wl,--as-needed -pipe -march=native -fPIC -O2 -o libopcodes.la -rpath /usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1 dis-buf.lo disassemble.lo dis-init.lo i386-dis.lo i386-opc.lo ../bfd/libbfd.la -L/var/tmp/portage/sys-devel/binutils-2.37_p1-r2/work/build/opcodes/../libiberty/pic -liberty -Wl,-lc,--as-needed,-lm,--no-as-needed -inst-prefix-dir /var/tmp/portage/sys-devel/binutils-2.37_p1-r2/image)
lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a' generated with LTO version 11.2 instead of the expected 12.0
compilation terminated.
lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.

[Comment 23 pigfoot 2022-07-06 05:32:19 UTC]

sys-devel/binutils-2.37_p1-r3 still encountered (In reply to Sebastian L. from comment #20)
> >  sys-devel/binutils/binutils-2.37_p1-r3.ebuild | 476
> > +++++++++++++++++++++++++
> >  sys-devel/binutils/binutils-2.38-r3.ebuild    | 484
> > ++++++++++++++++++++++++++
> >  sys-devel/binutils/binutils-9999.ebuild       |  21 +-
> >  3 files changed, 978 insertions(+), 3 deletions(-)
> 
> Andreas, I ran into this issue today.
> Unmasked 2.37_p1-r3, but it still referenced libiberty.a from
> /usr/lib64/binutils:

> 
> So the -r3 probably doesn't solve the issue.

Just a shareing that binutils-2.37_p1-r3 cannot solve this issue, but binutils-2.38-r3 can be built for me.
I cannot figure out why, but hope it helps to solve this issue.

[Comment 24 Andreas K. Hüttel 2022-07-07 10:54:22 UTC]

Indeed, what I changed did not prevent install-time relinking,
and as far as I can understand the situation, relinking is also
correct here.

So forget about 2.37_p1-r3 and 2.38-r3, I'll probably just revert
that. 

What is incorrect is the library search dir for relinking.
Diving into automake... (/&%(/&)(/&/&%/&%$

[Comment 25 Andreas K. Hüttel 2022-07-07 12:22:27 UTC]

OK so I can confirm that this bug is gone in 2.38

[Comment 26 pigfoot 2022-07-08 03:13:55 UTC]

So before official fixing, let me consolidate the workaround based on from m1027.
Backup step is not necessary, but just reference.

#
# Not necessary to remove pgo USE in make.conf
#
# emerge binutils-libs to get libiberty.a
sudo emerge -av1 sys-libs/binutils-libs

# Force link to binutils-libs
BINUTILS_LIBIBERTY="$(equery -C -N b libiberty.a | sed -En '/^sys-devel\/binutils/ s#.*\((.*)\)#\1#p')"
BINUTILS_LIBS_LIBIBERTY="$(equery -C -N b libiberty.a | sed -En '/^sys-libs\/binutils-libs/ s#.*\((.*)\)#\1#p')"

sudo cp -av "${BINUTILS_LIBIBERTY}" "${BINUTILS_LIBIBERTY}.BAK"
sudo ln -sf "${BINUTILS_LIBS_LIBIBERTY}" "${BINUTILS_LIBIBERTY}"


# emerge should work, and "${BINUTILS_LIBIBERTY}" would be new
sudo emerge -av1 sys-devel/binutils

# remove backup file
sudo rm "${BINUTILS_LIBIBERTY}.BAK"

[Comment 27 Larry the Git Cow 2022-07-09 11:43:06 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de8ab91328eacd19cfe93d78f6bac4b3dd332c46

commit de8ab91328eacd19cfe93d78f6bac4b3dd332c46
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2022-07-07 10:55:14 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2022-07-09 11:42:49 +0000

    Revert "sys-devel/binutils: Prevent relinking on install, try 1"
    
    This reverts commit 8ea456d072e46530ea53f04fe8935693fab59093.
    
    This plainly didn't work. What I changed did not prevent install-time
    relinking, and as far as I understand the situation now, relinking is also
    correct here.
    
    So forget about 2.37_p1-r3 and 2.38-r3, I'll add -r4 versions in a later
    commit.
    
    What is incorrect is the library search dir for relinking.
    
    Bug: https://bugs.gentoo.org/834720
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 sys-devel/binutils/binutils-2.37_p1-r3.ebuild | 476 -------------------------
 sys-devel/binutils/binutils-2.38-r3.ebuild    | 484 --------------------------
 sys-devel/binutils/binutils-9999.ebuild       |  21 +-
 3 files changed, 3 insertions(+), 978 deletions(-)

[Comment 28 ernsteiswuerfel 2022-11-23 19:41:33 UTC]

Have not seen this on binutils-2.38-r2 nor 2.39-r4 on my amd64/ppc64/ppc machines. Seems it was fixed for good.

[Comment 29 thulle 2022-11-23 19:46:03 UTC]

I also perceive this as fixed on my amd64 workstation.

[Comment 30 Zdenek Sojka 2023-01-24 19:39:20 UTC]

I still observe this after update from gcc-11 to gcc-12 on an amd64 box, with binutils-2.39:

lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.39/libiberty.a' generated with LTO version 11.3 instead of the expected 12.0

[Comment 31 Daniel Santos 2023-02-06 19:20:30 UTC]

The problem is that -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.39 doesn't belong in the relink command. I'm not intimately familiar with how libtool works, but trying to dig through it is UGLY. This is during the install-bfdlibLTLIBRARIES target and we don't want this option during install -- if it needs to re-link, it can use what we've already built

[Comment 32 Sam James 2023-02-09 01:33:53 UTC]

Indeed. This isn't fixed yet as nothing fundamental has changed here and it likely just stopped appearing for folks as a coincidence wrt GCC upgrade timing.

Note that the relinking seems to happen on a vanillaish build from a fresh git clone: https://bugs.gentoo.org/893428#c4, so at least it's probably not our fault.

[Comment 33 Sam James 2023-02-18 14:03:58 UTC]

If you hit this, try:
mv /usr/lib64/binutils/x86_64-pc-linux-gnu/2.39/libiberty.a{,.bak}

(replace the version as appropriate.)

[Comment 34 Andreas K. Hüttel 2023-02-22 20:46:04 UTC]

Created attachment 853998 [details, diff]
experimental patch

Please try the attached experimental patch (it was made against 2.40).

[Comment 35 Andreas K. Hüttel 2023-02-22 22:00:42 UTC]

Created attachment 854020 [details, diff]
experimental patch

Updated patch. This might fix it. Please test and give feedback here.

[Comment 36 Conrad Kostecki 2023-03-12 19:16:40 UTC]

Patch fixed for me https://bugs.gentoo.org/900905

But compilation of binutils reports:
 * QA Notice: Files built without respecting CFLAGS have been detected
 *  Please include the following list of files in your report:
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/bfd-plugins/libdep.so
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/libopcodes-2.40.0.gentoo-sys-devel-binutils-mt.so
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/libctf-nobfd-2.40.0.gentoo-sys-devel-binutils-mt.so
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/libctf-2.40.0.gentoo-sys-devel-binutils-mt.so
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/libbfd-2.40.0.gentoo-sys-devel-binutils-mt.so
 * /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40/libsframe.so.0.0.0


 * QA Notice: Package triggers severe warnings which indicate that it
 *            may exhibit random runtime failures.
 * /var/tmp/portage/sys-devel/binutils-2.40-r3/work/binutils-2.40/opcodes/ft32-dis.c:30:30: warning: type of 'ft32_opc_info' does not match original declaration [-Wlto-type-mismatch]

I am not sure, if that has anything todo with the patch.

[Comment 37 Sam James 2023-03-13 20:35:01 UTC]

*** Bug 900905 has been marked as a duplicate of this bug. ***

[Comment 38 Artemis Everfree 2023-03-26 09:24:18 UTC]

patch fixed for me as well

[Comment 39 Larry the Git Cow 2023-04-02 11:44:38 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/toolchain/binutils-patches.git/commit/?id=b359e23310a3269a6b25f49fa0c962364ece0fc5

commit b359e23310a3269a6b25f49fa0c962364ece0fc5
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2023-04-02 11:43:34 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2023-04-02 11:43:34 +0000

    Apply build fix for libiberty to libopcodes and libgprofng
    
    To be upstreamed properly
    
    Bug: https://bugs.gentoo.org/834720
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 ...ilar-libiberty-fix-as-in-7d53105d-for-lib.patch | 84 ++++++++++++++++++++++
 1 file changed, 84 insertions(+)

[Comment 40 Larry the Git Cow 2023-04-02 12:21:04 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6623c4f3139d0b9690466bccc5f57313ff175828

commit 6623c4f3139d0b9690466bccc5f57313ff175828
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2023-04-02 12:19:32 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2023-04-02 12:20:52 +0000

    sys-devel/binutils: patchlevel bump, 2.39 p6
    
    Bug: https://bugs.gentoo.org/834720
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 sys-devel/binutils/Manifest                |   1 +
 sys-devel/binutils/binutils-2.39-r5.ebuild | 499 +++++++++++++++++++++++++++++
 2 files changed, 500 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1400d06aaa484260e63e7181a2b9dddd464efcd

commit d1400d06aaa484260e63e7181a2b9dddd464efcd
Author:     Andreas K. Hüttel <[e-mail]>
AuthorDate: 2023-04-02 12:00:56 +0000
Commit:     Andreas K. Hüttel <[e-mail]>
CommitDate: 2023-04-02 12:20:49 +0000

    sys-devel/binutils: patchlevel bump, 2.40 p4
    
    Bug: https://bugs.gentoo.org/834720
    Signed-off-by: Andreas K. Hüttel <[e-mail]>

 sys-devel/binutils/Manifest                |   1 +
 sys-devel/binutils/binutils-2.40-r4.ebuild | 503 +++++++++++++++++++++++++++++
 2 files changed, 504 insertions(+)

[Comment 41 Sam James 2023-04-03 05:42:58 UTC]

For completeness: https://inbox.sourceware.org/binutils/[e-mail]/.

[Comment 42 Andreas K. Hüttel 2023-05-06 17:53:23 UTC]

>  sys-devel/binutils/binutils-2.39-r5.ebuild | 499

This is stable now.