[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible problem with gettext.m4 for binutils

From: Nick Alcock
Subject: Re: Possible problem with gettext.m4 for binutils
Date: Mon, 08 Feb 2021 15:17:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3.50 (gnu/linux)

On 8 Feb 2021, Stephen Casner outgrape:

> 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/libiconf.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}.

To be (even) more pedantic, binutils doesn't really care overmuch about
the symbols provided by libiconv: but like most things it *does* care
that you only link against one libiconv consistently. Most libraries GDB
uses (like, say, libbfd) pick up /usr/lib/libiconv.dylib on Stephen's
system... but...

> 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.

... that -L/opt/local/lib needed for libgmp drags in *another* libiconv
in the link of gdb itself which is incompatible with the libiconv used
by bfd etc.

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).

(There are vaguely similar problems with the builtin libintl in GCC and
binutils, which I've just submitted a patch series to fix. It's possible
that some of that series needs to go upstream to gettext as well: I'm
not sure, and I thought it best that the binutils and GCC folk look at
it first, since about 90% of the series isn't intl/-specific.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]