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

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

[Nick Alcock]

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

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

[Stephen Casner]

On Thu, 4 Feb 2021, Nick Alcock wrote:
> On 4 Feb 2021, Stephen Casner told this:
> > 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.

An initial reply just to be clear: this is not a new problem caused by
your changes.  I have encountered since I began working on binutils
and gcc for pdp11 a year ago.

                                                        -- Steve

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

[Stephen Casner]

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

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

[Nick Alcock]

On 4 Feb 2021, Stephen Casner told this:

> On Thu, 4 Feb 2021, Nick Alcock wrote:
>> On 4 Feb 2021, Stephen Casner told this:
>> > 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.
>
> An initial reply just to be clear: this is not a new problem caused by
> your changes.  I have encountered since I began working on binutils
> and gcc for pdp11 a year ago.

Oh right, phew! Well, it's possible I fixed it anyway: give the branch a
try :)

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

[Andrew Burgess]

* Nick Alcock <nick.alcock@oracle.com> [2021-02-04 20:35:23 +0000]:

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

Sorry for causing this breakage.

I've now reverted commit 82a1fd3a4935 while I think of a better way to
make this change.

One thing that would be helpful is, do you know if there's a non-elf
targeting triple that I could configure GDB for that would allow me to
make sure I don't break this again?

Thanks,
Andrew

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

[Christian Biesinger]

On Tue, Feb 9, 2021 at 10:49 PM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
> One thing that would be helpful is, do you know if there's a non-elf
> targeting triple that I could configure GDB for that would allow me to
> make sure I don't break this again?

I'm not the OP but some non-ELF triples I am aware of:
arm-none-eabi
x86_64-w64-mingw32
x86_64-apple-darwin20.3.0

Christian