Re: Bring back the intl subdirectory please

[Mark Kettenis <kettenis@gnu.org>]

   From: Andreas Schwab <schwab@suse.de>
   Date: Sat, 22 Jan 2005 20:12:32 +0100

   "Eli Zaretskii" <eliz@gnu.org> writes:

   >> Date: Sat, 22 Jan 2005 17:04:43 +0100 (CET)
   >> From: Mark Kettenis <kettenis@gnu.org>
   >> 
   >> There are now several bug reports about gdb 6.3 being broken due to
   >> missing libintl.h.  Basically all non-GNU systems are broken, unless
   >> GNU gettext was installed on the system.
   >> 
   >> Andrew, can you add it back please.
   >
   > Seconded.

   Modern gettext uses AM_GNU_GETTEXT(external) for this.  Maybe time to dump
   CY_GNU_GETTEXT?

That may not be such a bad idea, but there is a more fundamental
problem here.  GDB shares the bfd/ and opcodes/ with binutils.  Since
these directories are gettext-ized, we cannot change the way we handle
gettext without changing binutils too.  This is where things went
wrong in the first place; we removed intl/ from the GDB distribution
but it is still distributed with binutils, and everything in bfd/ and
opcodes/ still assumes it's there.  So as a short-term fix I really
think we should simply add back intl/ to the GDB distribution.

Then we (GDB and binutils) should consider what to do with intl/.  We
have basically two options:

1. Drop intl/ and only enable NLS if an external libintl is available
   (which on GNU/Linux systems is available as part of glibc).  We'll
   need to upgrade the configuration magic in bfd/, opcodes/, gdb/,
   binutila/, gas/ and ld/.  I've tried this for bfd/, opcode/ and
   gdb/ which seems to work reasonably well.

2. Update intl/.  We can either upgrade to the gettext used by GCC or
   a more recent version.  The GCC version is probably easier since it
   already has the modifications needed for the layout of our source
   tree.

There is of course the third option:

3. We give shit about anything that's not GNU.  GNU/Linux is now so
   dominant that we don't care about other systems.  Users of non-free
   software deserve what they get and should not complain.

I hope that option doesn't have any backers.

Anyway, the argument for option #1 is that intl/ might not build
properly on some (presumably) non-GNU systems.  I've never encountered
such a system on the recent past, and I only have a vague recollection
about intl/ not building properly on a system because there was a
broken install of GNU gettext on that system.  The argument for option
#2 obviously is that it would give everyone a properly gettext-ized
GDB and binutils.

Personaly I don't really care about internationalization, so I'd vote
for #1.

Mark