My host system has lto while the ROOT system does not. sys-devel/flex has not been build for a long time (it was last build with gcc 13) on my host system. In the ROOT system however, sys-devel/flex has been recently build without LTO support. While compiling net-dialup/linux-atm for ROOT, the linker is not able to link against libfl.a because 'generated with LTO version 13.0 instead of the expected 14.0' which suggests libfl.a of the host system is being used instead of ROOT for net-dialup/linux-atm which is being built for ROOT. If I copy up libfl.a from the ROOT to the host, net-dialup/linux-atm compiles fine. Modifying the ebuild to add sys-devel/flex to DEPEND does not help. While building for ROOT I've the following environment variables set -- export ROOT=/upgrade/ export PORTAGE_CONFIGROOT=/upgrade/ export SYSROOT=/upgrade/ Reproducible: Always for emerge --info see the attachment
Created attachment 901795 [details] emerge --info for both ROOT and host.
Created attachment 901796 [details] Failed build log for net-dialup/linux-atm-2.5.2-r1
It's not a Portage bug. It's two issues: 1) flex is a tool for _CBUILD_ because it has to be executed during cross-compilation 2) The general static-libs vs LTO thing (bug 926120) The package is missing a BDEPEND on flex, but that's the only new bug here. Otherwise, your issue is just bug 926120.
I'm not concerned about LTO, I'm concerned about the fact that libfl.a on the host is machine specific (-march=native) and if such bytecode is copied from the host machine, it'll result in crashes on the ROOT machine ones it's copied over there (since it's an older machine having a different CPU manufacturer). Adding flex to BDEPEND did not help.
(In reply to dE from comment #4) > I'm not concerned about LTO, I'm concerned about the fact that libfl.a on > the host is machine specific (-march=native) and if such bytecode is copied > from the host machine, it'll result in crashes on the ROOT machine ones it's > copied over there (since it's an older machine having a different CPU > manufacturer). The reason it fails: LTO bitcode. The reason it doesn't matter: it's a tool __purely__ for CBUILD, it gets built, executed, results kept, and the tool is thrown away.
that is, nothing linked against libfl will ever be installed.
Ok. that's great then, thanks.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd25aa948453fae21f85d607bde480904da451d6 commit dd25aa948453fae21f85d607bde480904da451d6 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-05-02 00:30:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-05-06 08:45:08 +0000 sys-devel/flex: use dot-a.eclass for LTO This means that USE=static-libs doesn't produce a "broken" library when built w/ LTO. Closes: https://bugs.gentoo.org/592868 Closes: https://bugs.gentoo.org/616106 Closes: https://bugs.gentoo.org/876430 Closes: https://bugs.gentoo.org/924183 Closes: https://bugs.gentoo.org/936172 Closes: https://bugs.gentoo.org/938858 Closes: https://bugs.gentoo.org/940541 Closes: https://bugs.gentoo.org/944291 Closes: https://bugs.gentoo.org/945923 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/flex/flex-2.6.4-r6.ebuild | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
