https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-misc/spread-5.0.1 fails to compile. Discovered on: amd64 (internal ref: tinderbox) NOTE: This machine uses a clang/LLVM toolchain. If you think that this issue is strictly related to clang/LLVM please block bug 408963. If you think that this issue is strictly related to the LLD linker, please block bug 731004. This machine uses also GLIBC-2.32. If you think that this issue is strictly related to GLIBC please block bug 736174.
Created attachment 658918 [details] build.log build log and emerge --info
tinderbox has reproduced this issue with version 5.0.1-r1 - Updating summary.
-Wl,-O1 is a standard mechanism in GNU toolchains for passing arguments to the linker via the C/C++ compiler. I *think* GNU ld in binutils is smart enough to accept -Wl,* syntax as well as the operand argument directly. I don't run clang, so I can't directly test this package to directly see what the core issue is. That said, grepping the source directory, I cannot find //any// references to -Wl,-O1 being passed anywhere. It looks like this value is passed by Portage itself, because if I undefine LDFLAGS in /etc/portage/make.conf, the following default LDFLAGS get passed: Host: x86_64-pc-linux-gnu Compiler: x86_64-pc-linux-gnu-gcc [snip] Linker flags: -Wl,-O1 -Wl,--as-needed -fno-lto -fno-use-linker-plugin Libraries: -lm -lnsl But if I explicitly set LDFLAGS to "" in make.conf: Host: x86_64-pc-linux-gnu Compiler: x86_64-pc-linux-gnu-gcc [snip] Linker flags: -fno-lto -fno-use-linker-plugin Libraries: -lm -lnsl So this seems to confirm that it's a Portage default somewhere that is trying to pass -Wl,-O1, and if the LLVM LLD doesn't like that argument format, that's an issue that needs to be taken up with LLVM upstream. As for Spread itself, the ebuild needs some minor TLC, but there has been no activity out of upstream in a few years, last post to their mailing list was June 2020, and their SVN repository is locked behind a public key authentication portal for unknown reasons, so I can't check to see what, if any development has happened. That said, the website is up and running, so I will assume the software is still supported and/or developed, just at an amazingly-slow pace. Marking bug as INVALID as the reported issue does not seem to be caused by the package itself.
I think the best fix is probably to just stop calling $(LD), really, given it's been deprecated for yeaaaars.
(In reply to Sam James from comment #4) > I think the best fix is probably to just stop calling $(LD), really, given > it's been deprecated for yeaaaars. Neither of the ebuild's invoke LD directly. It looks like that's the Makefiles in the source. I am tempted to leave that for Upstream to fix at some point, if they are still alive. I am not terribly familiar with the under-the-hood workings of this package. I only picked maintenance of it several years ago because it was a dependency for a netflow analysis package I made local ebuilds for that I don't really mess with anymore and which were never committed to the tree because of some unresolved licensing questions I ran into (software was sponsored by the US DoD and thus is dual-licensed under GPL2 and US DoD DFARS -- we don't have handling for DFARS).
I guess that here the problem is that LD is used during link instead of CC
