| Summary: | 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 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ernsteiswuerfel <erhard_f> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alex.iris.parker, conikost, dilfridge, gentoo, matoro_bugzilla_gentoo, sam, th-gen, tomek |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=838925 https://bugs.gentoo.org/show_bug.cgi?id=147155 https://bugs.gentoo.org/show_bug.cgi?id=893428 https://sourceware.org/bugzilla/show_bug.cgi?id=29042 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 838925, 868111 | ||
| Attachments: |
build.log (amd64)
emerge --info build.log (x86, USE=vanilla) experimental patch experimental patch |
||
Created attachment 766476 [details]
emerge --info
Discovered a 2nd workaround (besides binutils-2.38): Building binutils-2.37_p1-r2 with clang and afterwards with gcc again works too. 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. (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.) (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. Created attachment 766638 [details]
build.log (x86, USE=vanilla)
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.
(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. 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... 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. (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). (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??? My gcc was built with lto and I get this error message. (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. (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. (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 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} Problem introduced by commit b023986de7d466d361798bae98f45f8ba7a42e8a (HEAD) Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: Sat Apr 7 11:40:14 2018 +0100 Commit: Sergei Trofimovich <slyfox@gentoo.org> 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 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 <dilfridge@gentoo.org> AuthorDate: 2022-06-12 19:43:40 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> 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(-) (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 <dilfridge@gentoo.org> > AuthorDate: 2022-06-12 19:43:40 +0000 > Commit: Andreas K. Hüttel <dilfridge@gentoo.org> > 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 <dilfridge@gentoo.org> > > 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. 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):
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. 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. 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... (/&%(/&)(/&/&%/&%$ OK so I can confirm that this bug is gone in 2.38 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"
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 <dilfridge@gentoo.org> AuthorDate: 2022-07-07 10:55:14 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> 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(-) 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. I also perceive this as fixed on my amd64 workstation. 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 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 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. If you hit this, try:
mv /usr/lib64/binutils/x86_64-pc-linux-gnu/2.39/libiberty.a{,.bak}
(replace the version as appropriate.)
Created attachment 853998 [details, diff]
experimental patch
Please try the attached experimental patch (it was made against 2.40).
Created attachment 854020 [details, diff]
experimental patch
Updated patch. This might fix it. Please test and give feedback here.
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. *** Bug 900905 has been marked as a duplicate of this bug. *** patch fixed for me as well 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 <dilfridge@gentoo.org> AuthorDate: 2023-04-02 11:43:34 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> ...ilar-libiberty-fix-as-in-7d53105d-for-lib.patch | 84 ++++++++++++++++++++++ 1 file changed, 84 insertions(+) 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 <dilfridge@gentoo.org> AuthorDate: 2023-04-02 12:19:32 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> AuthorDate: 2023-04-02 12:00:56 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> 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 <dilfridge@gentoo.org> sys-devel/binutils/Manifest | 1 + sys-devel/binutils/binutils-2.40-r4.ebuild | 503 +++++++++++++++++++++++++++++ 2 files changed, 504 insertions(+) For completeness: https://inbox.sourceware.org/binutils/20230228224937.3832887-1-dilfridge@gentoo.org/. > sys-devel/binutils/binutils-2.39-r5.ebuild | 499
This is stable now.
|
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.