Re: Bring back the intl subdirectory please

Re: Bring back the intl subdirectory please

[Mark Kettenis]

[Sorry misspelled binutils@sources.redhat.com in the first post]

   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

Re: Bring back the intl subdirectory please

[Eli Zaretskii]

> Date: Sun, 23 Jan 2005 15:13:17 +0100 (CET)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: eliz@gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com
> 
> 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.

Me too.

> Anyway, the argument for option #1 is that intl/ might not build
> properly on some (presumably) non-GNU systems.

Even if that is true, it couldn't do any more harm than now, since
i18n in GDB is currently broken on _all_ non-GNU systems.

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

Even if we don't care about i18n, it wouldn't be nice to go for #1
because of the i18n-related work already invested in GDB (by Baurjan
and others).

Re: Bring back the intl subdirectory please

[Ian Lance Taylor]

Mark Kettenis <kettenis@gnu.org> writes:

> 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.

This seems clearly desirable to me.  We can then simply keep intl in
synch with gcc.

Ian

Re: Bring back the intl subdirectory please

[Mark Kettenis]

   Date: Mon, 24 Jan 2005 16:23:47 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Mark Kettenis wrote:
   >    Date: Mon, 24 Jan 2005 14:51:27 -0500
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    Mark,
   > 
   >    You are aware of this patch, right?
   >    http://sources.redhat.com/ml/gdb-patches/2005-01/msg00232.html
   > 
   > I might not be reading that patch right, but AFAICT that still assumes
   > that GNU gettext is available (either in libc or as a seperately
   > installed package).

   As I noted in my original post, I'm not in a position to test it so some 
     help would be appreciated.  Can you do that?

It seems to help on sparc-sun-solaris2.7, but that system has a
libintl of its own.

On sparc-unknown-freebsd5.3 however, I get:

make  all-recursive
Making all in doc
Making all in po
make: don't know how to make frNONE. Stop
*** Error code 1

Stop in /usr/home/kettenis/src/obj/bfd.
*** Error code 1

Stop in /usr/home/kettenis/src/obj/bfd.
*** Error code 1

Stop in /usr/home/kettenis/src/obj.

and I'm sure that's not the only problem.

There seems to be some support for importing the intl/ subdirectory
from GCC, and I'll try to get that done.  However I really think we
should restore the old intl/ ASAP and release a fixed GDB 6.3.1 if
possible.

Mark

Re: Bring back the intl subdirectory please

[Andrew Cagney]

> It seems to help on sparc-sun-solaris2.7, but that system has a
> libintl of its own.

Well, my attempt to build on solaris 2.7 worked even prior to applying 
my patch.  Ditto for IRIX.

> On sparc-unknown-freebsd5.3 however, I get:
> 
> make  all-recursive
> Making all in doc
> Making all in po
> make: don't know how to make frNONE. Stop
> *** Error code 1
> 
> Stop in /usr/home/kettenis/src/obj/bfd.
> *** Error code 1
> 
> Stop in /usr/home/kettenis/src/obj/bfd.
> *** Error code 1

Was that CVS, or a nightly snapshot?

Remember, CVS requires that the developer install many tools including 
bison and flex.  The snapshots should not.

If this is occuring with a snapshot then we've a real bug.

Andrew

Re: Bring back the intl subdirectory please

[Mark Kettenis]

>
>> It seems to help on sparc-sun-solaris2.7, but that system has a
>> libintl of its own.
>
> Well, my attempt to build on solaris 2.7 worked even prior to applying
> my patch.  Ditto for IRIX.
>
>> On sparc-unknown-freebsd5.3 however, I get:
>>
>> make  all-recursive
>> Making all in doc
>> Making all in po
>> make: don't know how to make frNONE. Stop
>> *** Error code 1
>>
>> Stop in /usr/home/kettenis/src/obj/bfd.
>> *** Error code 1
>>
>> Stop in /usr/home/kettenis/src/obj/bfd.
>> *** Error code 1
>
> Was that CVS, or a nightly snapshot?

This is straight out of CVS.

> Remember, CVS requires that the developer install many tools including
> bison and flex.  The snapshots should not.

I've been building from CVS before on that machine from my normal build
tree that still includes intl/.  All the necessary tools are present on
that system.

> If this is occuring with a snapshot then we've a real bug.

We have a real bug, trust me!

Mark

Re: Bring back the intl subdirectory please

[Andrew Cagney]

>>>On sparc-unknown-freebsd5.3 however, I get:
>>>
>>>make  all-recursive
>>>Making all in doc
>>>Making all in po
>>>make: don't know how to make frNONE. Stop
>>>*** Error code 1
>>>
>>>Stop in /usr/home/kettenis/src/obj/bfd.
>>>*** Error code 1
>>>
>>>Stop in /usr/home/kettenis/src/obj/bfd.
>>>*** Error code 1
>>
>>Was that CVS, or a nightly snapshot?
> 
> 
> This is straight out of CVS.

Can you please test a snapshot.

Andrew

Re: Bring back the intl subdirectory please

[Mark Kettenis]

   Date: Wed, 26 Jan 2005 12:12:56 -0500
   From: Andrew Cagney <cagney@gnu.org>

   >>>On sparc-unknown-freebsd5.3 however, I get:
   >>>
   >>>make  all-recursive
   >>>Making all in doc
   >>>Making all in po
   >>>make: don't know how to make frNONE. Stop
   >>>*** Error code 1
   >>>
   >>>Stop in /usr/home/kettenis/src/obj/bfd.
   >>>*** Error code 1
   >>>
   >>>Stop in /usr/home/kettenis/src/obj/bfd.
   >>>*** Error code 1
   >>
   >>Was that CVS, or a nightly snapshot?
   > 
   > 
   > This is straight out of CVS.

   Can you please test a snapshot.

There's no reason whatsoever why that should be different, but I just
tested gdb-6.3.50.20050126.tar.bz2 on i386-unknown-openbsd3.6, and I
get exactly the same failure:

make  all-recursive
Making all in doc
Making all in po
make: don't know how to make frNONE. Stop in /home/kettenis/tmp/obj/bfd/po.
*** Error code 1

Stop in /home/kettenis/tmp/obj/bfd (line 1023 of Makefile).
*** Error code 1

Stop in /home/kettenis/tmp/obj/bfd (line 902 of Makefile).
*** Error code 1

Stop in /home/kettenis/tmp/obj (line 2488 of Makefile).


Mark