libctf, gdbsupport: intl/ problems with --with-included-gettext (was Re: [PATCH] ld: depend on libctf)

[Nick Alcock]

[Redirected back to binutils@. See bug 27297 for the background.]

[In brief: please try the fix on the users/nalcock/included-gettext
 branch. It may fail because I haven't run it through my entire test
 matrix yet...]

On 2 Feb 2021, Stephen Casner outgrape:

> On Sun, 31 Jan 2021, Stephen Casner wrote:
>> I have file bug 27297 for this problem.  I hope that you or someone
>> else more familiar with the build system than I am can take it or at
>> least suggest other tests I should do.
>
> I used git bisect to find that this problem arose with your commit
> 1038406a8f6609ad0a449746da70393b0835f699 that introduced CTF_LIBADD.

Ooh thank you! Really useful debugging :)

Needless to say this behaviour change was not intended.

> Part of the change was to include an explicit reference to the
> libintl.a file (through $(LIBINTL)), whereas the references to
> libiberty and libz are with -L and -l.  If I patch Makefile.in to use
> -L../intl -lintl then that avoide the broken libctf.a in my build.

Well, that's definitely a bug (though I still don't understand what's
going on with that libctf.a.)

This reveals a hole in my testing: all my autobuilders have a system
libintl or gettext in glibc: none are using the system libintl.
Unfortunately --with-included-gettext doesn't work, with the included
libintl seeming to be incompatible with itself:

/usr/local/ctf/bin/gcc -c  -O2 -g -L/usr/local/lib -L/usr/lib   -DHAVE_CONFIG_H  -I. -I../../intl plural.c
In file included from ../../intl/plural.y:35:
../../intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse'
  102 | # define PLURAL_PARSE libintl_gettextparse
      |                       ^~~~~~~~~~~~~~~~~~~~
../../intl/plural.y:40:25: note: in expansion of macro 'PLURAL_PARSE'
   40 | # define __gettextparse PLURAL_PARSE
      |                         ^~~~~~~~~~~~
plural.c:201:5: note: in expansion of macro '__gettextparse'
  201 | int __gettextparse (void);
      |     ^~~~~~~~~~~~~~
../../intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here
  102 | # define PLURAL_PARSE libintl_gettextparse
      |                       ^~~~~~~~~~~~~~~~~~~~

This is apparently an incompatibility with Bison 3.0: since that Bison
is seven years old now, this seems... unfortunate. glibc has fixed it by
merging libintl from gettext 0.19. GCC has fixed it differently in
commits 2ca17e0a89ff6c37e17851a5bd7b0a03ee8de535 and
437eea66a4b010d8e94aa81c2b40ccf0588e5fab from April last year.

(They seem to apply without difficulty. I have a local patch syncing
this up and will submit it soon, so nobody else need bother.)

With that in place, and --with-included-gettext, I can replicate this:

/bin/sh ./libtool  --tag=CC   --mode=link /usr/local/ctf/bin/gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long  -I../../libctf/../zlib -O2 -g -L/usr/local/lib -L/usr/lib   -version-info 0:0:0  -Wl,--version-script='../../libctf/libctf.ver' -Wl,-rpath=/usr/local/ctf/lib -o libctf-nobfd.la -rpath /usr/local/ctf/lib libctf_nobfd_la-ctf-archive.lo libctf_nobfd_la-ctf-dump.lo libctf_nobfd_la-ctf-create.lo libctf_nobfd_la-ctf-decl.lo libctf_nobfd_la-ctf-error.lo libctf_nobfd_la-ctf-hash.lo libctf_nobfd_la-ctf-labels.lo libctf_nobfd_la-ctf-dedup.lo libctf_nobfd_la-ctf-link.lo libctf_nobfd_la-ctf-lookup.lo libctf_nobfd_la-ctf-open.lo libctf_nobfd_la-ctf-sha1.lo libctf_nobfd_la-ctf-string.lo libctf_nobfd_la-ctf-subr.lo libctf_nobfd_la-ctf-types.lo libctf_nobfd_la-ctf-util.lo  -L/usr/home/nix/binutils/build/libctf/../libiberty -liberty ./../intl/libintl.a -liconv -L./../zlib -lz 

libtool: link: ar  cru .libs/libctf-nobfd.a ./../intl/libintl.a  libctf_nobfd_la-ctf-archive.o libctf_nobfd_la-ctf-dump.o libctf_nobfd_la-ctf-create.o libctf_nobfd_la-ctf-decl.o libctf_nobfd_la-ctf-error.o libctf_nobfd_la-ctf-hash.o libctf_nobfd_la-ctf-labels.o libctf_nobfd_la-ctf-dedup.o libctf_nobfd_la-ctf-link.o libctf_nobfd_la-ctf-lookup.o libctf_nobfd_la-ctf-open.o libctf_nobfd_la-ctf-sha1.o libctf_nobfd_la-ctf-string.o libctf_nobfd_la-ctf-subr.o libctf_nobfd_la-ctf-types.o libctf_nobfd_la-ctf-util.o

[nix@freebsd /usr/home/nix/binutils/build]$ ar t libctf/.libs/libctf-nobfd.a | less
libintl.a
libctf_nobfd_la-ctf-archive.o
(...)

Observe the direct reference to ./../intl/libintl.a, rather than
-L../intl -lintl. I bet that's the root of this. (It doesn't break any
platform I've tried it on, but it's still pretty clearly wrong.)

> I don't know how to get that form automatically pulled into
> Makefile.am.  Would that be a proper fix for this problem?

Even if this is fixed, linking with --enable-shared fails because
libintl is not built with -fPIC: even if that is fixed the obvious way,
gdbsupport breaks because it links shared libraries that need gettext
even when --disable-shared is specified!


I have a possible fix for all of this against a slightly old trunk on
the users/nalcock/included-gettext branch: could you try it out? (It's
several commits long, so pointing you at the git branch seems the
easiest way to have you test it.)

(The gdbsupport part, at least, needs reporting as a bug, but I can't do
that yet and I don't recommend anyone else try: when I tried, my bz
account was reported for 'inappropriate content' and locked for
spamming. Yaaaay. Reported to overseers@... I suppose that's the danger
of distributed operations like gdbserver enables: it's intrinsically
racy!)