Trying to build webkit-gtk with mold as the linker currently fails: CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:69 (message): The C compiler "/usr/bin/x86_64-pc-linux-gnu-gcc" is not able to compile a simple test program. ... mold: unknown command line option: --no-keep-memory That "--no-keep-memory" flag is appended by the ebuild and looks like it is not critical, so hopefully this is an easy fix.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa8c75638bbc8e9d35f33478ab3b0e18b83f19dc commit aa8c75638bbc8e9d35f33478ab3b0e18b83f19dc Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-16 02:44:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-16 02:45:48 +0000 net-libs/webkit-gtk: test if linker supports --no-keep-memory For example, mold doesn't. Closes: https://bugs.gentoo.org/831282 Signed-off-by: Sam James <sam@gentoo.org> net-libs/webkit-gtk/webkit-gtk-2.34.3.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks, but... that actually doesn't help when using GCC with "-fuse-ld=mold". The flagomatic test is running, x86_64-pc-linux-gnu-g++ -Werror -std=c++17 -xc++ -c \ /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.cc \ -o /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.exe which checks that /usr/bin/ld (either ld.bfd or ld.gold, depending on binutils' USE flags) support the flag.
(In reply to Michael Orlitzky from comment #2) > Thanks, but... that actually doesn't help when using GCC with > "-fuse-ld=mold". The flagomatic test is running, > > x86_64-pc-linux-gnu-g++ -Werror -std=c++17 -xc++ -c \ > /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.cc \ > -o /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.exe > > which checks that /usr/bin/ld (either ld.bfd or ld.gold, depending on > binutils' USE flags) support the flag. Oh, ugh, I see. I'm really surprised we've not got a proper way of handling this?
(In reply to Sam James from comment #3) > (In reply to Michael Orlitzky from comment #2) > > Thanks, but... that actually doesn't help when using GCC with > > "-fuse-ld=mold". The flagomatic test is running, > > > > x86_64-pc-linux-gnu-g++ -Werror -std=c++17 -xc++ -c \ > > /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.cc \ > > -o /var/tmp/portage/net-libs/webkit-gtk-2.34.3/temp/test-flag.exe > > > > which checks that /usr/bin/ld (either ld.bfd or ld.gold, depending on > > binutils' USE flags) support the flag. > > Oh, ugh, I see. I'm really surprised we've not got a proper way of handling > this? ... it'd.. be enough to just respect ${LDFLAGS}?
(In reply to Sam James from comment #4) > > > > Oh, ugh, I see. I'm really surprised we've not got a proper way of handling > > this? > > ... it'd.. be enough to just respect ${LDFLAGS}? That was my first thought. It's probably OK, but it does change the meaning of the test from "does CCLD support this flag?" to "does CCLD support this flag along with $LDFLAGS"? I can imagine some (highly contrived) cases where the former is what's desired.
Try to use /usr/bin/mold as symlink of /usr/bin/ld instead of -fuse-ld=mold and see if it helps: I used to have some problems using -fuse-ld too
I opened bug 832377 for the eclass.
Can we band-aid this in the meantime? The gcc "-fuse-ld=mold" flag isn't free-form, so we could check *FLAGS for it without feeling too guilty.
Could this be the band aid? # Try to use less memory, bug #469942 (see Fedora .spec for reference) # --no-keep-memory doesn't work on ia64, bug #502492 local ldinuse=$(get-flag "fuse-ld") if ! use ia64 && [[ ${ldinuse} != "mold" ]] ; then append-ldflags $(test-flags-CCLD "-Wl,--no-keep-memory") fi
(In reply to rajas from comment #9) > Could this be the band aid? > > # Try to use less memory, bug #469942 (see Fedora .spec for reference) > # --no-keep-memory doesn't work on ia64, bug #502492 > local ldinuse=$(get-flag "fuse-ld") > if ! use ia64 && [[ ${ldinuse} != "mold" ]] ; then > append-ldflags $(test-flags-CCLD "-Wl,--no-keep-memory") > fi You might be able to shorten it a bit with "is-flagq", but yes, something easy like that is all it should take.
To my great confusion (trying to reproduce the failure), it looks like mold has gained the ability to parse & ignore this flag: https://github.com/rui314/mold/commit/bd3fa9a3db4c2 So a fair solution is: upgrade your sys-devel/mold.
