This is the mail archive of the
mailing list for the GDB project.
Re: Bring back the intl subdirectory please
[Sorry misspelled firstname.lastname@example.org in the first post]
From: Andreas Schwab <email@example.com>
Date: Sat, 22 Jan 2005 20:12:32 +0100
"Eli Zaretskii" <firstname.lastname@example.org> writes:
>> Date: Sat, 22 Jan 2005 17:04:43 +0100 (CET)
>> From: Mark Kettenis <email@example.com>
>> 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.
Modern gettext uses AM_GNU_GETTEXT(external) for this. Maybe time to dump
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
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