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

[Nick Alcock via Gdb-patches <gdb-patches@sourceware.org>]

[gcc-patches Cc:ed for the elfcore failure, not so much for the iconv
 stuff yet, since I'm revamping a lot of that stuff in bfd/opcodes/etc
 and that should probably get looked at before the gdb side, I guess.
 See the git branch referenced below.]

On 4 Feb 2021, Stephen Casner told this:

> On Thu, 4 Feb 2021, Nick Alcock wrote:
>
>> I've updated the users/nalcock/included-gettext branch on
>> binutils-gdb.git with a new approach which is rather less gross than the
>> horrible stuff I was doing before.
>>
>> It still seems to work for me: could you check to see if it still works
>> for you?
>
> This version introduces two new undefined symbols in the gdb link:

Oh dammit.

> Undefined symbols for architecture x86_64:
>   "_elfcore_write_prstatus", referenced from:
>       gcore_collect_regset_section_cb(char const*, int, int, regset const*, char const*, void*) in gcore.o
>   "_elfcore_write_register_note", referenced from:
>       gcore_collect_regset_section_cb(char const*, int, int, regset const*, char const*, void*) in gcore.o

I think this may not be my fault but rather is unrelated fallout from
commit 82a1fd3a4935fe665cf08bc6820942c4a091184c, which just landed.
As of this commit, elfcore_write_register_note et al are unconditionally
cited from gdb/gcore.c, but obviously these are only going to exist for
ELF platforms, which MacOS X is not.

> the gdb link fails with these undefined symbols:
>
>   "_iconv", referenced from:
>       __nl_find_msg in libintl.a(dcigettext.o)
>   "_iconv_close", referenced from:
>       __nl_free_domain_conv in libintl.a(loadmsgcat.o)
>   "_iconv_open", referenced from:
>       __nl_init_domain_conv in libintl.a(loadmsgcat.o)

Now *this* is probably, er... well, I'm not sure it's my fault because I
didn't touch gdb, only gdbserver and intl/ itself (in a way that
shouldn't have affected the way gdb uses it), but it's certainly
suboptimal.

gdb is linked with $(INTL), which is derived from @LIBINTL@, which
comes from intl/config.intl: I would have expected this to include
-liconv if needed

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

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?

> 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 run into the same problem building gcc, and use the same hack.  I've

Oh well. That can't be related to what I'm doing, then -- I haven't
touched the GCC tree.

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