Re: new gdb build failures on MacOS X (... fallout from libintl fixups, see users/nalcock/included-gettext)

[Stephen Casner <casner@acm.org>]

On Thu, 4 Feb 2021, Nick Alcock wrote:
> On 4 Feb 2021, Stephen Casner told this:
> > To satisfy those I need to hack the gdb/Makefile to append
> > /usr/lib/libiconv.dylib (the system libiconv, which is old) after two
> > instances of -liconv.  If I replace -liconv rather than appending then
> > I get three different undefined symbols:
>
> Hmm, so -liconv isn't loading /usr/lib/libiconv.dylib?

Sorry, I missed saying that -liconv gets /opt/local/lib/libiconv.{a,dylib}
which is the more current one that I installed.  I'm not sure how that
one is found.  I have tried --with-libiconv-prefix=/opt/local but, as
I mentioned, that causes -I./../intl to be removed from the bfd
compiles.

> The -L stuff I tore out of libopcodes and bfd (which might be relevant)
> is -L`pwd`/../libiberty/pic -L`pwd`/../intl -liberty -lintl, which also
> does not explicitly cite libiconv. (The libiberty stuff is brought back
> in a bit further up, and the intl stuff should be retained via
> $(LTLIBINTL) as well.)
>
> >   "_libiconv", referenced from:
>
> Oh wonderful. _iconv *and* _libiconv?

Right.  So I presume one of the libraries links with one of them and
the main links with the other.

> > So the gdb link requires two different iconv libraries presumably
> > because different parts of the build choose different references.
>
> Looks like it. A full log of the compilation of gdb/ at least (and
> preferably the whole build) might give more info about which bits are
> using what.

I will follow up on that.

> > been trying to figure out how to fix this properly but so far I have
> > not gained enough familiarity with the configure and Makefile morass
> > to find the answer.  There is a --with-libiconv-prefix option for gdb,
> > but when I include that it causes -I./../intl to be removed from the
> > compile commands for bfd
>
> Yeah, intl/ also has --with-libiconv-prefix, which is probably
> triggering this -- though that just sets --prefix for the intl/ tree,
> which I wouldn't really expect to cause this (but I've never tried that
> option, so I'm not sure).

I'll try looking more there, too.

I should also point out that the native compile on macOS does not
build as or ld for reasons that I don't yet understand.  So I should
probably test your branch for my cross pdp11 build as well.  That one
does not build gdb (since it would never fit in the 16-bit address
space).

                                                        -- Steve