Re: Possible problem with gettext.m4 for binutils

[Nick Alcock]

On 18 Oct 2024, Bruno Haible spake thusly:

> Hi,
> Nick Alcock wrote:
>> To fix this, the -liconv gettext adds should be immediately preceded by
>> a -L citing its location, so that other -L's introduced by other
>> packages don't trigger this (which would cause gdb, too, to link against
>> /usr/lib/libiconv.dylib and all would be well).
>
> This is not a reliable fix.
>   * In the GNU Build System, -L options are supposed to be given in a
>     separate variable than -l options (LDFLAGS vs. LIBS) [1].

IMHO this is almost certainly a mistake.

>   * libtool is allowed to reorder these options.

Yes, but doing that is... unfortunate and also arguably a bug, given
that -L's semantics are order-dependent and entangled with -l: the
relative ordering of -L and -l should never be changed by tooling since
doing so can alter which libraries the -l's find. (Why would libtool
*want* to reorder them? What advantage does it have?)

LDFLAGS is useful for things like -s which aren't order-dependent, but
-L should really go in LIBS.

-- 
NULL && (void)