| Summary: | net-misc/spread-5.0.1-r1 fails to compile: ld.lld: error: unknown argument '-Wl,-O1' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Joshua Kinard <kumba> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Agostino Sarubbo
2020-09-07 06:49:23 UTC
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 |
