gcc/intl vs. src/intl

gcc/intl vs. src/intl

[Ian Lance Taylor]

So, I notice that gcc/intl and src/intl are pretty different.  And I
wonder how this can possibly work in the context of uberbaum.  I
suppose it will work fine on a host on which all the intl code can be
found in libc with no other dependencies--such as GNU/Linux.  On such
a host the intl directory will not be built, and code will simply link
with -lc.  But on a host in which gcc/intl requires -liconv--such as
NetBSD, or Cygwin--the differing expectations of gcc/intl and src/intl
will cause conflict.

Has anybody looked into resolving this?  Presumably the correct
short-term fix is to bring gcc/intl over to src/intl, and update the
Makefiles accordingly.  Presumably the long-term fix would to keep
intl in sync as we keep libiberty in sync.  Does anybody have a better
idea?

Ian

Re: gcc/intl vs. src/intl

[DJ Delorie]

> Presumably the long-term fix would to keep intl in sync as we keep
> libiberty in sync.

Note: the key to doing this is automatically to let one repository
(presumably, src) relinquish control of src/intl to the other (gcc),
so that the sync scripts only have to work one way.  We do this for
libiberty.

Keeping them in sync automatically is not practical if patches are
allowed on both sides.  This is the case for toplevel.

Re: gcc/intl vs. src/intl

[Christopher Faylor]

On Tue, Nov 16, 2004 at 08:53:05PM -0500, Ian Lance Taylor wrote:
>So, I notice that gcc/intl and src/intl are pretty different.  And I
>wonder how this can possibly work in the context of uberbaum.  I
>suppose it will work fine on a host on which all the intl code can be
>found in libc with no other dependencies--such as GNU/Linux.  On such
>a host the intl directory will not be built, and code will simply link
>with -lc.  But on a host in which gcc/intl requires -liconv--such as
>NetBSD, or Cygwin--the differing expectations of gcc/intl and src/intl
>will cause conflict.
>
>Has anybody looked into resolving this?  Presumably the correct
>short-term fix is to bring gcc/intl over to src/intl, and update the
>Makefiles accordingly.  Presumably the long-term fix would to keep
>intl in sync as we keep libiberty in sync.  Does anybody have a better
>idea?

The other, more radical way of doing this is to get rid of uberbaum and
finally put gcc, gdb, and binutils under one repository.  cygwin, sid
and other non-GNU projects could keep using the src repository while
the other GNU projects could use the same infrastructure.

cgf