Created attachment 865210 [details] build log From the build log: ``` 439 │ /bin/sh ./libtool --tag=CC --mode=link clang -Wall -Wextra -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -O2 -pipe -march=znver3 -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--as-needed -Wl,--undefined-version -o libsframe.la -rpath /usr/lib64/binutils/x86_64-pc-linux-gnu/2.40 libsframe_la-sfram │ e.lo libsframe_la-sframe-dump.lo libsframe_la-sframe-error.lo 440 │ libtool: link: clang -shared -fPIC -DPIC .libs/libsframe_la-sframe.o .libs/libsframe_la-sframe-dump.o .libs/libsframe_la-sframe-error.o -Wl,--as-needed -march=znver3 -Wl,-O1 -Wl,--undefined-version -Wl,-soname -Wl,libsframe.so.0 -o .libs/libsframe.so.0.0.0 441 │ /usr/bin/x86_64-pc-linux-gnu-ld.bfd: unrecognized option '--undefined-version' 442 │ /usr/bin/x86_64-pc-linux-gnu-ld.bfd: use the --help option for usage information 443 │ clang-16: [0m0;1;31merror: linker command failed with exit code 1 (use -v to see invocation) ``` My take from this is that for some reason the gnu linker is being used instead of the requested clang one, but I'm not really sure.
Comment on attachment 865210 [details] build log The filename on the attachment is wrong, as seen in the logs this is for 2.40-r5
I have the same issue. It looks like libtool is calling directly clang as a linker, without passing the extra arguments present in LDFLAGS. /etc/portage/make.conf: LDFLAGS="-Wl,-O2 -Wl,--as-needed -fuse-ld=lld" relevant build line: libtool: link: clang -shared -fPIC -DPIC .libs/libsframe_la-sframe.o .libs/libsframe_la-sframe-dump.o .libs/libsframe_la-sframe-error.o -Wl,--as-needed -march=native -Wl,-O2 -Wl,--undefined-version -Wl,-soname -Wl,libsframe.so.0 -o .libs/libsframe.so.0.0.0 /usr/bin/x86_64-pc-linux-gnu-ld.bfd: unrecognized option '--undefined-version' FWIW: - forcing the environment variable LD=ld.lld for the merge, yields the same error. - forcing the compilation (via package.env) through gcc, yelds the same error (as expected, since it would have used ld.bfd by default) - forcing gcc to use mold (via LDFLAGS in package.env) yields the same error (it still calls ld.bfd) - I have no idea why the running binutils (2.39-r5) was built w/o the option --undefined-version.
You need to put -fuse-ld=lld in CFLAGS/CXXFLAGS too.
That didn't work here. Did it work for anyone else?
(Ie. even though I was trying to use lld, it was still trying to use my gnu ld, and failing with that message.)
I got it to work using the standard gnu ld ... ie. by removing -fuse-ld=lld from {C,LD}FLAGS
