PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]


This is an FYI to binutils/gdb only; I'm not yet touching anything
over in /cvs/src.

This patch removes the obsolete (0.10.40) libintl which GCC had in
gcc/intl; instead, I bring in the latest (0.12.1) libintl and put it
at top level, matching binutils/gdb which has had a top level 'intl'
directory for some time.  (Note that the libintl they have is even
older than GCC's current one - it dates to 1998 and does not appear to
have a version number.)

The autoconf macros distributed with gettext will not work in this
arrangement, so I'm using the gettext.m4 from binutils CVS - but I've
moved it to config/ which is where we seem to be keeping aclocal
fragments these days.  This file is badly in need of revision but not
right this instant, and this change is invasive enough already.

I tested this patch as follows:

  - Full bootstrap on i686-linux with no special options, which uses
    the libintl that's part of glibc.  In this setting the intl
    directory is configured but not built.

  - Configured with --with-included-gettext and did make all-gcc, then
    verified that the intl directory's implementation was getting
    used, and that message translation worked.
  - Configured with --disable-nls and did make all-gcc, then verified
    that cc1 didn't use gettext at all.

  - Dropped the intl subdirectory into a binutils tree, without
    modifying anything else, built it with --with-included-gettext,
    and verified that message translation still worked.

The attached diff reproduces the patch in full - created and deleted
files both.  However, generated files are not included.

OK to apply?

zw


[-- Attachment #2: changelog --]
[-- Type: text/plain, Size: 1503 bytes --]

top:
	* intl: New directory; see intl/ChangeLog for details.
	* ABOUT-NLS, config.rpath: Import from gettext 0.12.1.
	* Makefile.tpl: all-gcc depends on maybe-all-intl.
	* Makefile.in: Regenerate.
config:
	* gettext.m4: New file - copy of gettext.m4 from binutils
	CVS, with added AC_ISC_POSIX macro from gcc/aclocal.m4.
gcc:
	* ABOUT-NLS: Delete.
	* intl: Delete entire directory.
	* aclocal.m4: Include ../config/gettext.m4.  Delete
	AC_ISC_POSIX, AM_LANGINFO_CODESET, jm_GLIBC21, AM_LC_MESSAGES,
	AM_PATH_PROG_WITH_TEST, AM_WITH_NLS, and AM_GNU_GETTEXT.
	* configure.in: Use CY_GNU_GETTEXT, not AM_GNU_GETTEXT.
	Remove intl/Makefile from all_outputs.
	* configure, config.in: Regenerate.
	* Makefile.in: Expunge all references to intl subdirectory.
	Add -I../intl to INCLUDES.
	* intl.h: Include libintl.h if and only if ENABLE_NLS is defined.
intl:

	* Makefile.in: Remove unnecessary capabilities for
	installation, build of shared libraries, generation of
	distribution tarballs, etc.  Fix all the places that rely on
	the parent directory.  Don't generate libgnuintl.h from
	anything; do generate $(objdir)/libintl.h from libgnuintl.h if
	necessary.  Adjust DEFS for use of config.h.
	* README: New file.
	* config.charset, ref-add.sin, ref-del.sin: Delete (unused).
	* COPYING.LIB-2.0, COPYING.LIB-2.1: Delete (redundant).
	* aclocal.m4: New; generated per instructions in gettext manual.
	* configure.in: New; written from scratch for this configuration.
	* configure, config.h.in: Generated.


[-- Attachment #3: move-libintl.diff.gz --]
[-- Type: application/gzip, Size: 232650 bytes --]

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Andrew Pinski]

On Wednesday, Jul 2, 2003, at 23:38 US/Eastern, Zack Weinberg wrote:
> OK to apply?

One question, right now libintl is compiled three times while
bootstrapping, one for each stage, does this still hold with your patch?

Thanks,
Andrew Pinski

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Wednesday, Jul 2, 2003, at 23:38 US/Eastern, Zack Weinberg wrote:
>> OK to apply?
>
> One question, right now libintl is compiled three times while
> bootstrapping, one for each stage, does this still hold with your patch?

No.  It is now built just once, like libiberty.  I don't think this
should be a problem.

zw

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Alexandre Oliva]

On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> 	* ABOUT-NLS, config.rpath: Import from gettext 0.12.1.

I'm disgusted at the duplication of outdated code from libtool in
config.rpath, and about other assumptions about libtool in intl's
autoconf macros.  However, none of this is your fault, so, unless
we try to get upstream gettext to avoid this, we'll have to go with
the flow.

Unless others bring up any further issues, or think we should stick
with the old version of intl that is present in the src tree, please
go ahead and check the whole thing in.  Thanks for doing this.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Alexandre Oliva]

On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> OK to apply?

Oh, wait!  This will break uberbaum, unless binutils, gdb and
everybody else switches to the new intl/ at the same time.  So I'd
rather wait for them to accept the changes, but that's just me,
because I happen to use uberbaum for unified-tree builds.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:
>
>> OK to apply?
>
> Oh, wait!  This will break uberbaum, unless binutils, gdb and
> everybody else switches to the new intl/ at the same time.

It shouldn't.  The uberbaum intl/ symlink points to /cvs/src/src/intl,
so you'll get the old libintl, which is harmless.  GCC has no
dependency on the precise version of libintl in use.

zw

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:
>
>> 	* ABOUT-NLS, config.rpath: Import from gettext 0.12.1.
>
> I'm disgusted at the duplication of outdated code from libtool in
> config.rpath, and about other assumptions about libtool in intl's
> autoconf macros.  However, none of this is your fault, so, unless
> we try to get upstream gettext to avoid this, we'll have to go with
> the flow.

Note that I removed the capability to create a shared libintl.a from
intl/Makefile.in, so we aren't going to get burnt by any outdated
information.  I agree the gettext autoconf macros are horrible,
though.

zw

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Alexandre Oliva <aoliva@redhat.com> writes:
>
>> On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:
>>
>>> OK to apply?
>>
>> Oh, wait!  This will break uberbaum, unless binutils, gdb and
>> everybody else switches to the new intl/ at the same time.
>
> It shouldn't.  The uberbaum intl/ symlink points to /cvs/src/src/intl,
> so you'll get the old libintl, which is harmless.  GCC has no
> dependency on the precise version of libintl in use.

I have now verified this, by building GCC with --with-included-gettext
and the libintl from binutils, as it would be in an uberbaum
configuration.

zw

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Alexandre Oliva]

On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> I have now verified this, by building GCC with --with-included-gettext
> and the libintl from binutils, as it would be in an uberbaum
> configuration.

Thanks.  No further potential objections from me, then :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Alexandre Oliva]

On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:

> Note that I removed the capability to create a shared libintl.a from
> intl/Makefile.in

Maybe it would be appropriate to remove the supporting code from its
aclocal.m4, then, such that we don't need this new config.rpath
script and the other attempts at reinventing libtool poorly :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: PATCH: replace obsolete GCC libintl with top-level libintl from newest gettext distribution

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jul  3, 2003, "Zack Weinberg" <zack@codesourcery.com> wrote:
>
>> Note that I removed the capability to create a shared libintl.a from
>> intl/Makefile.in
>
> Maybe it would be appropriate to remove the supporting code from its
> aclocal.m4, then, such that we don't need this new config.rpath
> script and the other attempts at reinventing libtool poorly :-)

I considered doing that but I decided it was too complicated, and
would interfere too much with future imports of upstream gettext.

zw