[PATCH] Use LDFLAGS when testing linker flags

[PATCH] Use LDFLAGS when testing linker flags

[Nicholas Wilson]

Hi,

This is another patch for the WebAssembly build.

In Wasm, we currently need to pass some extra flags to the linker, and LDFLAGS would seem to be a good way to do this.

The patch below tests the linker by passing LDFLAGS on the link line. This ought to be a safe change to make?

Thanks,
Nick

=======
commit a951daab68b4b6ee6f46278f02df279188559b89
Author: Nicholas Wilson <nicholas.wilson@realvnc.com>
Date:   Thu Dec 7 15:42:58 2017 +0000

    [Wasm] Use LDFLAGS when testing linker

diff --git a/configure b/configure
index f320660d..519d31fa 100755
--- a/configure
+++ b/configure
@@ -98,7 +98,7 @@ fi
 tryldflag () {
 printf "checking whether linker accepts %s... " "$2"
 echo "typedef int x;" > "$tmpc"
-if $CC $LDFLAGS_TRY -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
+if $CC $LDFLAGS $LDFLAGS_TRY -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
 printf "yes\n"
 eval "$1=\"\${$1} \$2\""
 eval "$1=\${$1# }"

Re: [PATCH] Use LDFLAGS when testing linker flags

[Rich Felker]

On Thu, Dec 07, 2017 at 04:03:03PM +0000, Nicholas Wilson wrote:
> Hi,
> 
> This is another patch for the WebAssembly build.
> 
> In Wasm, we currently need to pass some extra flags to the linker, and LDFLAGS would seem to be a good way to do this.
> 
> The patch below tests the linker by passing LDFLAGS on the link line. This ought to be a safe change to make?
> 
> Thanks,
> Nick
> 
> =======
> commit a951daab68b4b6ee6f46278f02df279188559b89
> Author: Nicholas Wilson <nicholas.wilson@realvnc.com>
> Date:   Thu Dec 7 15:42:58 2017 +0000
> 
>     [Wasm] Use LDFLAGS when testing linker
> 
> diff --git a/configure b/configure
> index f320660d..519d31fa 100755
> --- a/configure
> +++ b/configure
> @@ -98,7 +98,7 @@ fi
>  tryldflag () {
>  printf "checking whether linker accepts %s... " "$2"
>  echo "typedef int x;" > "$tmpc"
> -if $CC $LDFLAGS_TRY -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
> +if $CC $LDFLAGS $LDFLAGS_TRY -nostdlib -shared "$2" -o /dev/null "$tmpc" >/dev/null 2>&1 ; then
>  printf "yes\n"
>  eval "$1=\"\${$1} \$2\""
>  eval "$1=\${$1# }"
> 

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.

Rich

Re: [PATCH] Use LDFLAGS when testing linker flags

[Nicholas Wilson]

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