Re: Possible problem with gettext.m4 for binutils

[Bruno Haible]

Hi,

Stephen Casner wrote in
<https://lists.gnu.org/archive/html/bug-gettext/2021-02/msg00000.html>:
> When building a native binutils on macOS [1] I get unresolved
> references to libiconv.  Nick Alcock helped investigate this and
> concluded that the root of the problem lies in gettext.m4, so he
> suggested that I send this email to bug-gettext.  Specifically, the
> problem may be that when gettext decides that -liconv must be included
> it does not also include -L to make sure the loaded library is the one
> that it has chosen.
> 
> On many systems this may not be a problem because there is only one
> libiconv.  However, in my macOS the system /usr/lib/libiconv.dylib is
> an older version that defines _iconv, _iconv_close, _iconv_open.  That
> system version is protected so I can't change it.  But some of the
> binutils code requires a newer libiconv that defines _libiconv,
> _libiconv_close, _libiconv_open.  I have installed that library using
> MacPorts as /opt/local/lib/libiconv.{a,dylib}.
> 
> In order to build gdb, I also need libgmp, libmpc, libmpfr, so I have
> also installed those with MacPorts into /opt/local/lib.  In order to
> include them in the build, I need to include the configure option
> --with-libgmp-prefix=/opt/local which causes -I/opt/local/include and
> -L/opt/local/lib to be included in the compile and link commands for
> the gdb files.  Therefore those files expect the _libiconv symbols.
> 
> However, libintl is also included in the gdb link, but its configure
> tests find the system libiconv so I get unresolved _iconv symbols from
> dcigettext.o and loadmsgcat.o.

Yes, this is a known shortcoming of the combination of
  1) the design of -L and -l options, where you don't specify the location
     of individual libraries but directories to search for,
  2) the desire to have multiple packages installed with the same --prefix.

The way to make this work reliably is that the person who builds the
package sets CPPFLAGS and LDFLAGS before running the top-level configure:

  env CPPFLAGS="-L/opt/local/include -Wall" LDFLAGS="-L/opt/local/lib" \
      ../configure ...

Then all sub-configures will search for libraries in /opt/local first,
and this gets rid of the link error.

> An alternative of
> specifying LDFLAGS=-L/opt/local/lib on the binutils configure causes
> the same bfd compilation failure.

You always need to set CPPFLAGS and LDFLAGS in a consistent way.

> I don't know if the system
> libiconv would be sufficient on the later macOS releases.

macOS 14 and 15 have broken libiconv by default. On these platforms
you do need GNU libiconv (e.g. through Homebrew or MacPorts).

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].
  * libtool is allowed to reorder these options.

Bruno

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Preset-Output-Variables.html