On all of my amd64 and x86 systems, emerge of sys-libs/compiler-rt-14.0.6 fails. The error occurs during cmake and reads: "Please use architecture with 4 or 8 byte pointers" The corresponding source code is in compiler-rt/cmake/config-ix.cmake: if (NOT CMAKE_SIZEOF_VOID_P EQUAL 4 AND NOT CMAKE_SIZEOF_VOID_P EQUAL 8) message(FATAL_ERROR "Please use architecture with 4 or 8 byte pointers.") endif() I tried to replace the message by message(FATAL_ERROR CMAKE_SIZEOF_VOID_P) but the output is only “CMAKE_SIZEOF_VOID_P”. So it seems to me that the variable CMAKE_SIZEOF_VOID_P is simply not substituted as it should be. The error occurs with dev-util/cmake-3.22.4 as well as with dev-util/cmake-3.23.3. Removing the above check from the config-ix.cmake file let emerge run though on x86 and amd64. But this is of course not a proper fix since CMAKE_SIZEOF_VOID_P is tested in some further places, so I guess that on either x86 or amd64 something is not compiled correctly. Anyway, so far I observed no problems with the fix. But, I did no serious testing yet (for instance, compilation of firefox after that is not yet finished...)
Possibly a duplicate of bug #862639 but hard to say without seeing emerge --info or the build.log (e.g. I can reproduce if I use -flto=thin, but otherwise no issues).
Created attachment 796573 [details] emerge --info
Yes, probably a dupe: For most packages (in particular, llvm, clang, lld, cmake), I passed -flto -fuse-linker-plugin -flto-partition=none -flto-odr-type-merging However, sys-libs/compiler-rt-14.0.6 failed to emerge even if I do not pass any flags to cmake and compiler-rt. compiler-rt[-clang] indeed emerges when not passing any flags.
Correction: llvm was compiled without -flto* as well, and clang without -flto-partition*. I will try to compile now clang without all -flto* as well (will take a few hours) and report back afterwards.
Recompiling clang without -flto* did not solve the problem, either. It is perhaps remarkable that there are 3 strange messages at the very beginning: Make Warning at cmake/Modules/CompilerRTUtils.cmake:287 (message): LLVM source tree not found at "/srv/tmp/portage/sys-libs/compiler-rt-14.0.6/work/llvm". You are not using the monorepo layout. This configuration is DEPRECATED. Call Stack (most recent call first): CMakeLists.txt:70 (load_llvm_config) CMake Warning at cmake/Modules/CompilerRTUtils.cmake:315 (message): Consulting llvm-config for the LLVM source path as a fallback. This behavior will be removed in the future. Call Stack (most recent call first): CMakeLists.txt:70 (load_llvm_config) -- Using LLVM source path (/dev/null) from llvm-config CMake Warning at cmake/Modules/CompilerRTUtils.cmake:352 (message): llvm-config finding testingsupport failed with status 1 Call Stack (most recent call first): CMakeLists.txt:70 (load_llvm_config)
Recompiling ldd without any cflags solved the problem. Therefore, I mark the bug is invalid. (Flags like flto are not supported.) Sorry for the noise.
Just for the records: clang may very well be compiled with -flto without any problems (so far, up to my knowledge). What must *not* be compiled with -flto are: - sys-devel/lld-14.0.6 - sys-libs/compiler-rt-14.0.6 and probably - sys-devel/llvm (The first two trigger the issue reported in the bug, and the latter caused problems with -flto already in earlier versions.)
*** Bug 862639 has been marked as a duplicate of this bug. ***
I am not clear how this can be an invalid bug. I've always built clang/lld/llvm/compiler-rt with `-flto=thin -fuse-ld=lld`. Something is broken.
(In reply to Markus Peloquin from comment #9) > I am not clear how this can be an invalid bug. I've always built > clang/lld/llvm/compiler-rt with `-flto=thin -fuse-ld=lld`. > > Something is broken. The maintainer didn't close it, the reporter did. But compiling with LTO is not invalid. If it's unsupported for a particular package, we should filter appropriately, at the very least.
Haven't tried but maybe that's because -flto=thin got removed by strip-unsupported-flags before? Formerly flag-o-matic tested flags individually and =thin wouldn't work without -fuse-ld=lld (thus stripped). But now it uses it, likely keeps it, and the build reacts badly to this.
(In reply to Ionen Wolkens from comment #11) > [...] > individually and =thin wouldn't work without -fuse-ld=lld (thus stripped). Well correction, it works with llvmgold I think (haven't experimented), albeit combination of flags could still have ended up broken stripping some.
I've been digging around and here's what I found: Since commit 828d8bf14cac680b319b107412d1eda05661436f ("sys-libs/compiler-rt: add -nostartfiles to nolib_flags") the ebuilds add -nostartfiles to LDFLAGS to avoid bootstrapping failures with pure LLVM setups. Obviously it doesn't make a difference for the compile phase (no linking involved), configuration is still broken, just differently; that hack doesn't work as it is. The problem isn't visible in the build log, but if you check CMake's log files (${WORKDIR}/compiler-rt-14.0.6_build/CMakeFiles/CMakeOutput.log and CMakeError.log), there are warnings for every test binary: /usr/bin/x86_64-pc-linux-gnu-ld: warning: cannot find entry symbol _start; defaulting to 0000000000001000 (or something similar). The resulting binaries are not only broken because of an invalid entry point (that doesn't matter much because they are never run), but also main() is no longer referenced by anything. So when the linker can removes unused symbols (e.g. with -flto or -Wl,--gc-sections), it can simply drop all code and data of the test programs—not good. The result is and empty ABI test program, the extracted ABI data recorded in ${WORKDIR}/compiler-rt-14.0.6_build/CMakeFiles/3.22.4/CMakeC{,XX}Compiler.cmake becomes emtpy, too, and that causes the error message ("Please use architecture with 4 or 8 byte pointers.") Some other configure checks fail in a different way, e.g. library checks in a multilib setup. After the linker failed to resolve the entry symbol with the libs from /usr/lib64 (and doesn't need it for other symbols because it dropped all code) it falls back to /usr/lib and errors out because the libs found there have incompatible ABIs. But that wouldn't result in a build failure. (Only tangentially related, but mentioning while I'm at it: I also see failed checks because flag-o-matic's strip-unsupported-flags doesn't filter flags that only produce "argument unused during compilation: …" warnings with clang and the checks use -Werror. I think those flags should be stripped, too. At least I can't think of a good reason to keep them, and apparently they're causing not only log spam, but real problems.) So, how can we fix the -nostartfiles hack? It's tempting to filter all flags that could cause the linker to drop unused sections or symbols. But IMHO a better approach is to add -emain to LDFLAGS; thus we have a defined entry point and the symbol main is referenced, solving both problems. The binaries will still be somewhat broken (which doesn't matter as mentioned above), but they should link properly. (Also -nodefaultlibs -nostartfiles could be replaced with -nostdlib I think?)
(In reply to Alexander Miller from comment #13) > I've been digging around and here's what I found: > > Since commit 828d8bf14cac680b319b107412d1eda05661436f ("sys-libs/compiler-rt: > add -nostartfiles to nolib_flags") the ebuilds add -nostartfiles to LDFLAGS > to avoid bootstrapping failures with pure LLVM setups. Obviously it doesn't > make a difference for the compile phase (no linking involved), configuration > is still broken, just differently; that hack doesn't work as it is. > FWIW, I've changed the logic a bit for bug 862540 (which, as a result of your analysis, I now realise is related to this bug). > [snip] > (Only tangentially related, but mentioning while I'm at it: I also see failed > checks because flag-o-matic's strip-unsupported-flags doesn't filter flags > that only produce "argument unused during compilation: …" warnings with > clang and the checks use -Werror. I think those flags should be stripped, > too. > At least I can't think of a good reason to keep them, and apparently they're > causing not only log spam, but real problems.) > There is some historical context here (see flag-o-matic.eclass itself), but also bug 712488 and bug 714742. But not against changing it if someone has a goof suggestion. > So, how can we fix the -nostartfiles hack? It's tempting to filter all flags > that could cause the linker to drop unused sections or symbols. But IMHO a > better approach is to add -emain to LDFLAGS; thus we have a defined entry > point and the symbol main is referenced, solving both problems. The binaries > will still be somewhat broken (which doesn't matter as mentioned above), but > they should link properly. (Also -nodefaultlibs -nostartfiles could be > replaced with -nostdlib I think?) Good idea. Could you possibly do two things for me please? 1. Poke at the 15.0.0.9999 ebuild and see whether the "runtimes" build actually works for all of our cases (this isn't so important, I guess, but it'd be nice to know if there's edge-cases it can't handle); 2. Prepare a patch against 14.0.6-r1?
(In reply to Sam James from comment #14) > Good idea. Could you possibly do two things for me please? > > 1. Poke at the 15.0.0.9999 ebuild and see whether the "runtimes" build > actually > works for all of our cases (this isn't so important, I guess, but it'd be > nice to know if there's edge-cases it can't handle); > > 2. Prepare a patch against 14.0.6-r1? And I suppose... 3. Consider preparing a patch against flag-o-matic.eclass, in light of the above.
(In reply to Sam James from comment #14) Took a while, had a few more important things to do… > 1. Poke at the 15.0.0.9999 ebuild and see whether the "runtimes" build > actually > works for all of our cases (this isn't so important, I guess, but it'd be > nice to know if there's edge-cases it can't handle); Well, we're getting more off-topic, but since you asked: for me the ebuild fails to configure with the following error: | CMake Error at /tmp/portage/sys-libs/compiler-rt-15.0.0.9999/work/compiler-rt/cmake/Modules/CompilerRTUtils.cmake:434 (string): | string sub-command REPLACE requires at least four arguments. | Call Stack (most recent call first): | /tmp/portage/sys-libs/compiler-rt-15.0.0.9999/work/compiler-rt/CMakeLists.txt:107 (construct_compiler_rt_default_triple) The last argument to that command, ${COMPILER_RT_DEFAULT_TARGET_TRIPLE}, is empty, hence the error. It's set to ${LLVM_TARGET_TRIPLE} earlier, but that one isn't defined; it's expected to be set in LLVMConfig.cmake of sys-devel/llvm, but the file from version 14.0.6-r2 only sets TARGET_TRIPLE (without LLVM prefix), which seems a bit odd. It took a while to figure out all that crap, but I got it to build with MYCMAKEARGS="-DLLVM_TARGET_TRIPLE=x86_64-pc-linux-gnu". It seems to work with any of the flags discussed above. I didn't test the pure LLVM bootstrap path, though. > 2. Prepare a patch against 14.0.6-r1? Done, what about -r0? (In reply to comment #15) > 3. Consider preparing a patch against flag-o-matic.eclass, in light of the > above. I think the -Qunused-arguments stuff is no longer needed and can simply be dropped. Let's see whether mgorny complains. Silencing the warnings while keeping the unused flags would be possible, but much more complicated, and would need some refactoring. Further discussion in the PR, I suppose.
(In reply to Martin Väth from comment #7) > Just for the records: clang may very well be compiled with -flto without any > problems (so far, up to my knowledge). > What must *not* be compiled with -flto are: > > - sys-devel/lld-14.0.6 > - sys-libs/compiler-rt-14.0.6 > > and probably > > - sys-devel/llvm > > (The first two trigger the issue reported in the bug, and the latter caused > problems with -flto already in earlier versions.) On my production machine, it just compiles sys-libs/compiler-rt-14.0.6 without -flto=thin. Others are fine with -flto=thin.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8bb13b19b42601b8b57c5b1c2d64d1b0a04fede5 commit 8bb13b19b42601b8b57c5b1c2d64d1b0a04fede5 Author: Alexander Miller <alex.miller@gmx.de> AuthorDate: 2022-08-06 23:22:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-24 04:56:27 +0000 sys-libs/compiler-rt: Override start symbol when adding -nostartfiles to LDFLAGS Trying to link executables for the configure checks generates linker warnings (in the CMake logs) like: "warning: cannot find entry symbol _start; defaulting to 0000000000001000". Moreover, with flags like -flto or -Wl,--gc-sections, the linker can discard all code, rendering the checks useless. Set main as entry symbol when linking with -nostartfiles to avoid both issues. (Note that the binaries would still crash, but that doesn't matter since they are never executed.) Bug: https://bugs.gentoo.org/862540 Closes: https://bugs.gentoo.org/862798 Signed-off-by: Alexander Miller <alex.miller@gmx.de> Signed-off-by: Sam James <sam@gentoo.org> sys-libs/compiler-rt/compiler-rt-14.0.6-r1.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ddba1d149e82dba88b72f992729ad4158f640e32 commit ddba1d149e82dba88b72f992729ad4158f640e32 Author: Alexander Miller <alex.miller@gmx.de> AuthorDate: 2022-08-07 01:34:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-24 04:55:53 +0000 flag-o-matic.eclass: test-flag-PROG, strip unused args that generate warnings A number of configure checks used by CMake and autoconf (and probably other build systems) relies on warning-free compiler runs. A combination of compiler and flags that always generates warnings can cause misconfiguration and/or build failures. Since commit ae9870d9f6b1394ede86176443770b36d7e60ac1, flags that generate warnings that could be suppressed with -Qunused-arguments are accepted anyway to avoid stripping all linker flags (#627474). But commit 28d6437fc7009002f98f28e8900e994109927726 added linker invocation for linker flags tests, so the workaround shouldn't be necessary any more. Drop the extra -Qunused-arguments check and reject all flags that generate warnings to avoid configuration issues. If it turns out that stripping these unused flags is still problematic, we could accept them and actually add -Qunused-arguments to the relevant *FLAGS to silence the warnings, but that would require bigger changes, so let's try the simpler and cleaner solution first. Bug: https://bugs.gentoo.org/627474 Bug: https://bugs.gentoo.org/714742 Bug: https://bugs.gentoo.org/862798 Signed-off-by: Alexander Miller <alex.miller@gmx.de> Closes: https://github.com/gentoo/gentoo/pull/26773 Signed-off-by: Sam James <sam@gentoo.org> eclass/flag-o-matic.eclass | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b05d4a0ac1d854afa97048fa1fe166d0e123d61 commit 7b05d4a0ac1d854afa97048fa1fe166d0e123d61 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-08-24 04:58:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-24 04:58:55 +0000 sys-libs/compiler-rt: forward port nostartfiles fix Bug: https://bugs.gentoo.org/862540 Bug: https://bugs.gentoo.org/862798 See: 8bb13b19b42601b8b57c5b1c2d64d1b0a04fede5 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/compiler-rt/compiler-rt-14.0.6-r1.ebuild | 1 + sys-libs/compiler-rt/compiler-rt-15.0.0.9999.ebuild | 6 ++++-- sys-libs/compiler-rt/compiler-rt-15.0.0_rc2.ebuild | 6 ++++-- sys-libs/compiler-rt/compiler-rt-16.0.0.9999.ebuild | 6 ++++-- 4 files changed, 13 insertions(+), 6 deletions(-)
