Re: [PATCH] Use LDFLAGS when testing linker flags

[Nicholas Wilson <nicholas.wilson@realvnc.com>]

Hi Rich,

On 15 December 2017 04:34, Rich Felker wrote:
> I'm not sure this is a good idea. At make time, $(LDFLAGS) is applied
> after the auto-added ldflags from the various "try"s. If it's applied
> before when testing, the order in which things override will be
> different and might cause wrong test results.

> If there are flags that *need* to be passed in order for the toolchain
> to work, they might belong as part of $CC rather than any *FLAGS
> variable. But without seeing them it's hard to say. If this is needed
> we probably need to flip around the above order, at least.

It's sneaky to put some flags in $CC! That's actually how I'm bodging the libcxx (C++ standard library) build at the moment. Unfortunately Musl's configure script actually assumes you're not doing that. If you do "CC='clang -Wl,XXX' ./configure" then the check for whether the compiler accepts "-Werror=unused-command-line-argument" fails (because of course the linker flag indeed isn't used). Given that the Clang does support that argument, it would be good for the configure script not to detect it, which relies on not putting linker flags in $CC.

The arguments I'm currently using are specified with "-Wl,..." to pass some Wasm-specific linking paths. While we're developing the linker, the defaults haven't all been ironed out! Ultimately I believe the goal is that the linker's defaults should be usable with Musl, but I think support for LDFLAGS is a reasonable request in the meantime. The configure script already supports use of LDFLAGS lower down.

Thanks for your suggested improvement to put LDFLAGS at the end of the argument list, so that the tested order matches the order used later. That change makes sense. I've tested it, and it works with our toolchain (the LDFLAGS we're interested in can go in any order on the link-line).

Nick