configure sometimes misses passing LDFLAGS when testing linker

[Jameson Nash]

The failure we observe is:

> could not find a working compiler, see config.log for details

on line 7201 in `configure`.  Looking into the log, the failure is that the
compiler can’t find the compiler support libraries (e.g. `cannot find
-lgcc_s`) and as such it fails to link any of the tests that require
linking.

On Wed, Mar 27, 2019 at 3:09 PM Jameson Nash <vtjnash at gmail.com> wrote:

> OK, here's take 2, where I use that approach instead. You're right, this
> seems to a bit more precise about which calls to the compiler are using the
> linker. We don't want to try variations on them here yet, since we're just
> forwarding on the user's flags.
>
> On Tue, Mar 26, 2019 at 11:33 AM Niels Möller <nisse at lysator.liu.se>
> wrote:
>
>> Jameson Nash <vtjnash at gmail.com> writes:
>>
>> > There are a couple tests in ./configure which try to link binaries, but
>> > which don't propagate the LDFLAGS. In some cases, the compiler doesn't
>> work
>> > at all without those (notably, seen on FreeBSD when trying to use
>> new-ish
>> > gcc versions).
>>
>> For context, it would be good to know the resulting errors and the
>> missing flags for this failure case.
>>
>> > This patch updates configure.ac to pass along the linker
>> > flags to tests that are trying to use the linker. I think that's the
>> right
>> > fix?
>>
>> If the tests in configure.ac don't try variations of LDFLAGS, I think
>> it's better to add $LDFLAGS at the needed place(s) in the macro
>> definitions in acinclude.m4.
>>
>> From a quick look, GMP_PROG_CC_WORKS_PART_TEST looks like the only of
>> the related macros that depend on the linker; most tests invoke the
>> compiler with -c or -S.
>>
>> Regards,
>> /Niels
>>
>> --
>> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
>> Internet email is subject to wholesale government surveillance.
>>
>