Re: Can we have the intl directory back?

Re: Can we have the intl directory back?

[Paul Schlie]

>From: Daniel Jacobowitz <drow@false.org>
>> On Sat, Nov 20, 2004 at 06:07:56PM -0500, Paul Schlie wrote:
>> I have to confess being thoroughly confused about what is meant by:
>> 
>>  GNU vs. NON-GNU systems; and in what way it's relevant?
>> 
>> As if the term "GNU system" is being used as a euphemism for Linux,
>> implying that decisions may become increasing biased toward Linux, it
>> would be most unfortunate; as regardless of one's philosophical views,
>> uniform support of GNU tools for all reasonably significant POSIX based
>> platforms and supported targets likely remain fundamentally significant
>> to the GNU project's continued long term success, and should not become
>> confused by any potential desire affect Linux's longer term success at
>> the expense of others (which I trust isn't the intent or case).
> 
> You might want to take a look at the gnu.org web site, which describes
> this (and many other) aspect of the GNU project.  Remeber, GDB is the
> _GNU_ Debugger - part of a larger whole.
> 
> The GNU project's views disagree with you on the above.
> 
> Further discussion on this topic, however, seems to me to be off topic
> for a GDB development list - especially gdb-patches.  Take it to a
> general GNU forum.
> 
> -- 
> Daniel Jacobowitz

(Sorry, the context of the question was related to presumed int/ directory
installation, and it's effect on building GDB on GNU vs. non-GNU systems.)

And yes, there's some interesting dynamics at play, on one hand as the GNU
Hurd basically failed to gain sufficient support to ever be useful, GNU
seemingly politically high-jacked the Linux kernel + etc. (truly the OS,
although some apparently prefer to pretend otherwise) damn near claiming it
as it's own; although historically not developed under the sponsorship of
the FSF GNU project, although it did leverage GNU FSF sponsored tools,
libraries, and utilities developed, maintained on, and typically in support
of other operating systems, just as GNU had leveraged on work of others when
convenient.  But somewhat ironically, now Linux appears to be high-jacking
the historical work of the FSF GNU project as it's own, in many ways in
contradiction to the reasons that many had initially sought to contribute
to the GNU project (to establish and evolve what may have been naively
perceived to be a set of platform independent tools "free" of intellectual
encumbrance).

So with some hindsight, although unfortunate, now may be a good time for
those interested in unencumbered multi-platform tools, libraries, and
utilities; to abandon reliance on the GNU project, and begin maintaining
it's own set of sources which are more specifically maintained to be
multi-platform, although continue to leverage GNU/Linux tool, library, and
utility sources/patches as convenient; which might have some interesting
implications.

Re: Can we have the intl directory back?

[Eli Zaretskii]

> Date: Sat, 20 Nov 2004 11:01:20 +0100 (CET)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: ian@wasabisystems.com
> 
> So can we please add back the intl directory?

The problem with that is, Andrew says GDB will not build with that
intl directory on systems that actually need it (i.e. those which
don't have intl installed somewhere).  See the thread that started
here:

  http://sources.redhat.com/ml/gdb-patches/2004-07/msg00442.html

(and whose first message points to the Gnat report that describes the
problem), and the solution Andrew described at the end of the thread:

  http://sources.redhat.com/ml/gdb-patches/2004-08/msg00154.html

> The alternative of checking whether an installed intl is available
> would be acceptable too, but that requires coordination with
> binutils, since we'd have to duplicate that logic for the bfd
> subdirectory too.

I think this is the way to go, even if it is a bit harder.

But what bugs me is that in the latter of the above 2 messages, Andrew
says that the original intl/ directory would not build on non-GNU
systems, while you seem to say that it won't build without...  I think
we need to establish what is going on here, before we decide how to
fix it.

Can we have the intl directory back?

[Mark Kettenis]

I just discovered that we released a GDB 6.3 that will probably not
build out of the box on systems that don't have an installed libintl
in the default search path.  You can work around this by specifying
--disable-nls, but that sucks.  I didn't realize that our autoconfig
scripts don't default to --disable-nls if no usable libintl is found.
I didn't notice it because I never removed the intl directory from my
checked out CVS tree.

Now that I know this, Andrew's argument for not including the intl
subdirectory doesn't really make sense.  Instead of having to specify
--disable-nls on systems where the included intl doesn't build, you
now have to specify --disable-nls on almost all non-GNU systems.

So can we please add back the intl directory?  The alternative of
checking whether an installed intl is available would be acceptable
too, but that requires coordination with binutils, since we'd have to
duplicate that logic for the bfd subdirectory too.

There was a recent discussion about bringing over the intl stuff from
GCC.  I'm willing to spend some time on that if it means I get my intl
back ;-).

Mark