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 <[email protected]> wrote: > Jameson Nash <[email protected]> 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. >
acinclude.m4.patch
Description: Binary data
configure2.diff
Description: Binary data
_______________________________________________ gmp-bugs mailing list [email protected] https://gmplib.org/mailman/listinfo/gmp-bugs
