Re: Bring back the intl subdirectory please

Mark Kettenis
2005-01-23T14:09:44Z

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