[PATCH 0/8 RFC] unbreak --with-included-gettext, and other configury stuff

[PATCH 0/8 RFC] unbreak --with-included-gettext, and other configury stuff

[Nick Alcock]

Most of this series serves one goal: fixing problems Stephen Casner reported
with a binutils built --with-included-gettext or built on a platform that
doesn't have a gettext in a system libintl or in libc. This has long been broken
in binutils.

Firstly, two commits from last year that allow intl/ to build on systems with
Bison 3 are missing. That's easy to fix, but even with that fixed we have other
problems.  libctf would like to compile programs that use libctf.la in its
testsuite, without having to account for the fact that some of them might
include libintl symbols (i.e. it would like libctf.la to be complete, and
ideally libbfd.la too); but making these libraries complete is stymied by the
problem that you cannot link the built-in libintl symbols into shared libraries
on many platforms because it's not PIC. So we picize it, much as libiberty
already is. This then lets us fix gdbserver, which builds a preloaded shared
object and thus won't build without libintl if gettext isn't in libc.

That fixes the shared library case -- but then there's the problem Stephen
reported, which is that LIBINTL in intl/config.intl contains things like this:

LIBINTL='${top_builddir}/../libintl.a -liconv"

(sometimes without the -liconv part).

Linking with this doesn't work with static libraries on some platforms
(e.g. MacOS X) which build libintl.a *into* libctf.a or whatever other library,
and then fail to find symbols in it at build time because a .a file isn't an .o
file.  The solution here is to rewrite that into

LIBINTL='-L${top_builddir}/.. -lintl -liconv"

which always works, static or shared, library or not.

The way LIBINTL is transformed is a bit gross: rather than trickle changes
through gettext.m4 (which is frankly painful to contemplate: gettext.m4 has so
many other users and is so complicated...) we just modify the sedding that's
already done in the in-tree intl/configure.ac to sed the thing a bit
differently.

Doing this also lets us rip out some system-dependent hardwired gunge around
whether libintl comes from libc or not and replace it with using the results of
the checks intl/configure has already done.

Nothing seems to break: I've built and tested both binutils-gdb and gcc plus the
two libintl patches with --enable-shared and --disable-shared and with and
without --with-included-gettext on systems with gettext in libc, with gettext in
a system libintl and with no gettext anywhere.  Stephen has verified that MacOS X
(a system which had explicit system-dependent libintl gunge in
{bfd,opcodes,libctf}/configure.ac, all of which has gone away) gets further into
the build now (before failing in gdb for not-really-related reasons). Cygwin
(the other system with system-dependent gunge) has been able to have most of it
ripped out, and still builds as above.

Is this sort of thing acceptable? Probably for trunk only, unless people think
that the build failures on MacOS X merit backporting of this to the 2.36 release
branch.

(also in this series, some stuff not needing review: Tcl version checks for the
libctf testsuite and some small configury improvements to libctf.)

(All mails sent to binutils@sourceware.org: relevant subset Cc:ed to gdb and gcc
as well.)

Cc: gdb-patches@sourceware.org
Cc: gcc-patches@gnu.org

Jakub Jelinek (2): (sync from gcc)
  intl: Allow building both with old bison and bison >= 3 [PR92008]
  intl: Unbreak intl build with bison 3 when no regeneration is needed
    [PR92008]

Nick Alcock (6):
  intl: always picify
  intl: turn LIBINTL into -L / -l form
  bfd, opcodes, libctf: support --with-included-gettext
  gdbserver: explicitly include gettext, etc in inprocess agent
  libctf: require a Tcl capable of try/catch to run tests
  libctf: add missing header in BFD ELF check

 bfd/configure         |  11 ++--
 bfd/configure.ac      |  11 ++--
 gdbserver/Makefile.in |   2 +-
 intl/Makefile.in      |  16 ++++--
 intl/aclocal.m4       |   1 +
 intl/configure        | 113 +++++++++++++++++++++++++++++++++++++++++-
 intl/configure.ac     |  30 ++++++++++-
 intl/plural-config.h  |   1 +
 intl/plural-exp.h     |   8 ++-
 intl/plural.c         |  62 +++++++++++++++--------
 intl/plural.y         |  27 +++++++++-
 libctf/Makefile.am    |   6 ++-
 libctf/Makefile.in    |  91 +++++++++++++++++++---------------
 libctf/configure      |  91 +++++++++++++++++++++++++++++++---
 libctf/configure.ac   |  27 +++++++---
 opcodes/configure     |   8 ++-
 opcodes/configure.ac  |   8 ++-
 17 files changed, 413 insertions(+), 100 deletions(-)
 create mode 100644 intl/plural-config.h

-- 
2.30.0.252.gc27e85e57d

[PATCH 6/8] gdbserver: explicitly include gettext, etc in inprocess agent

[Nick Alcock]

The IPA uses gettext functionality, but does not link to $(LIBINTL), so
fails to link when --with-included-gettext is specified.

Now we are unconditionally building a PIC libintl, linking to $(LIBINTL)
gives us the right result even if a non-system libintl is in use.

Cc: gdb-patches@sourceware.org

gdbserver/ChangeLog
2021-02-02  Nick Alcock  <nick.alcock@oracle.com>

	* Makefile.in (IPA_LIB): Link with libintl.
---
 gdbserver/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdbserver/Makefile.in b/gdbserver/Makefile.in
index a14d3a7bc18..4a5ceab085a 100644
--- a/gdbserver/Makefile.in
+++ b/gdbserver/Makefile.in
@@ -404,7 +404,7 @@ $(IPA_LIB): $(sort $(IPA_OBJS)) ${CDEPS}
 	$(ECHO_CXXLD) $(CC_LD) -shared -fPIC -Wl,--soname=$(IPA_LIB) \
 		-Wl,--no-undefined $(INTERNAL_CFLAGS) $(INTERNAL_LDFLAGS) \
 		 $(CXXFLAGS) \
-		-o $(IPA_LIB) ${IPA_OBJS} $(LIBIBERTY_FOR_SHLIB) -ldl -pthread
+		-o $(IPA_LIB) ${IPA_OBJS} $(LIBIBERTY_FOR_SHLIB) $(INTL) -ldl -pthread
 
 # Put the proper machine-specific files first, so M-. on a machine
 # specific routine gets the one for the correct machine.
-- 
2.30.0.252.gc27e85e57d

Re: [PATCH 6/8] gdbserver: explicitly include gettext, etc in inprocess agent

[Tom Tromey]

>>>>> "Nick" == Nick Alcock via Binutils <binutils@sourceware.org> writes:

Nick> The IPA uses gettext functionality, but does not link to $(LIBINTL), so
Nick> fails to link when --with-included-gettext is specified.

This seems strange to me.

IIUC, IPA is intended to be a small library that is injected into the
inferior.  So, it seems to me that it should probably not use gettext.

Tom

Re: [PATCH 6/8] gdbserver: explicitly include gettext, etc in inprocess agent

[Nick Alcock]

On 8 Feb 2021, Tom Tromey stated:

>>>>>> "Nick" == Nick Alcock via Binutils <binutils@sourceware.org> writes:
>
> Nick> The IPA uses gettext functionality, but does not link to $(LIBINTL), so
> Nick> fails to link when --with-included-gettext is specified.
>
> This seems strange to me.
>
> IIUC, IPA is intended to be a small library that is injected into the
> inferior.  So, it seems to me that it should probably not use gettext.

  CXXLD  libinproctrace.so
/usr/bin/ld: ax-ipa.o: in function `ax_printf(unsigned long, unsigned long, char const*, int, unsigned long*) [clone .constprop.0]':
/home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/ax.cc:928: undefined reference to `libintl_gettext'
/usr/bin/ld: /home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/ax.cc:837: undefined reference to `libintl_gettext'
/usr/bin/ld: /home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/ax.cc:889: undefined reference to `libintl_gettext'
/usr/bin/ld: ax-ipa.o: in function `gdb_eval_agent_expr(eval_agent_expr_context*, agent_expr*, unsigned long*)':
/home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/ax.cc:1334: undefined reference to `libintl_gettext'
/usr/bin/ld: gdbsupport/common-utils-ipa.o: in function `xstrvprintf(char const*, __va_list_tag*)':
/home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/../gdbsupport/common-utils.cc:57: undefined reference to `libintl_gettext'
/usr/bin/ld: gdbsupport/common-utils-ipa.o:/home/oranix/oracle/private/binutils-gdb/x86_64-loom/gdbserver/../../gdbserver/../gdbsupport/common-utils.cc:57: more undefined references to `libintl_gettext' follow
collect2: error: ld returned 1 exit status

There are four translated errors in ax.cc... but if you fix those you
find more uses in ../gdbsupport/common-utils.cc and then that calls
gdb_assert which also translates the assertion string and this is
starting to feel like a tail-chasing nightmare where fixing it would do
significant damage to the translatability of GDB itself.

Maybe some sort of -include hackery that redefines _ to nothing would do
the trick, or something to unconditionally disable NLS and recompile
everything it calls upon out of gdbsupport similarly just for the IPA...
but I tried for a while and haven't succeeded yet.

Re: [PATCH 6/8] gdbserver: explicitly include gettext, etc in inprocess agent

[Nick Alcock]

On 8 Feb 2021, Nick Alcock via Binutils verbalised:

> On 8 Feb 2021, Tom Tromey stated:
>
>>>>>>> "Nick" == Nick Alcock via Binutils <binutils@sourceware.org> writes:
>>
>> Nick> The IPA uses gettext functionality, but does not link to $(LIBINTL), so
>> Nick> fails to link when --with-included-gettext is specified.
>>
>> This seems strange to me.
>>
>> IIUC, IPA is intended to be a small library that is injected into the
>> inferior.  So, it seems to me that it should probably not use gettext.

FYI: I do agree with this, but it seems to me that this is a distinct
(and much larger) patch from this one, which is merely making its
existing use of gettext explicit (so it doesn't break the build under
--with-included-gettext).