[Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Jeff Holcomb]

Preapproved by Alexandre Oliva.  Updated toplevel versions of these files 
to match net gcc.

2001-11-13  Jeff Holcomb  <jeffh@redhat.com>
        
        Merged from net gcc:
        2001-07-30  Jeff Sturm  <jsturm@one-pont.com>
        * ltcf-c.sh: Use $objext, not $ac_objext.
        2001-07-27  Mark Kettenis  <kettenis@gnu.org>
        * ltcf-cxx.sh: Add support for GNU.
        2001-07-22  Timothy Wall  <twall@redhat.com>
        * ltcf-c.sh: Don't disable shared libraries for AIX5/IA64.  Preserve
        default settings if using GNU tools with that configuration.
        * ltcf-cxx.sh: Ditto.
        * ltcf-gcj.sh: Ditto.
        2001-07-21  Michael Chastain  <chastain@redhat.com>
        * ltconfig: Set max_cmd_len to a maximum of 512Kb, as it seems some
        HPUX 11.0 systems have trouble with 1MB.  Mark as gcc-local.
        * ltmain.sh: Mark as gcc-local.


--
Jeff Holcomb
jeffh@redhat.com
GDB Engineering
Red Hat, Inc.

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Andrew Cagney]

Jeff,

Is there a reason for pulling in GCC's hacks rather than going to the 
official version per src/MAINTAINERS:

ltconfig; ltmain.sh
         libtool: http://gnu.org
         Changes need to be done in tandem with the official LIBTOOL
         sources or submitted to the master file maintainer and brought
         in via a merge.

If we pull in a GCC hack such as:

>  2001-07-21  Michael Chastain  <chastain@redhat.com>
> * ltconfig: Set max_cmd_len to a maximum of 512Kb, as it seems some
>         HPUX 11.0 systems have trouble with 1MB.  Mark as gcc-local.
>         * ltmain.sh: Mark as gcc-local.

then (no offence to MichaelC) we're taking on the responsibility of 
carrying that patch forward everytime a further import occures.

Andrew

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Jeff Holcomb]

On Wed, 14 Nov 2001, Andrew Cagney wrote:

> Is there a reason for pulling in GCC's hacks rather than going to the 
> official version per src/MAINTAINERS:
> 
> ltconfig; ltmain.sh
>          libtool: http://gnu.org
>          Changes need to be done in tandem with the official LIBTOOL
>          sources or submitted to the master file maintainer and brought
>          in via a merge.

It was my impression from Alexandre that he had already imported these 
changes from the official sources into gcc's tree.  For some reason, they 
weren't imported into the binutils/gdb tree at that time.

> If we pull in a GCC hack such as:
> 
> >  2001-07-21  Michael Chastain  <chastain@redhat.com>
> > * ltconfig: Set max_cmd_len to a maximum of 512Kb, as it seems some
> >         HPUX 11.0 systems have trouble with 1MB.  Mark as gcc-local.
> >         * ltmain.sh: Mark as gcc-local.
> 
> then (no offence to MichaelC) we're taking on the responsibility of 
> carrying that patch forward everytime a further import occures.

I understand this is in the official sources now, so it's not actually a 
gcc-local hack.  Perhaps the entry should be changed.

I do need this to be able to configure on our HPUX 11.0 systems.

--
Jeff Holcomb
jeffh@redhat.com
GDB Engineering
Red Hat, Inc.

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Andrew Cagney]

>> Is there a reason for pulling in GCC's hacks rather than going to the 
>> official version per src/MAINTAINERS:
>> 
>> ltconfig; ltmain.sh
>> libtool: http://gnu.org
>> Changes need to be done in tandem with the official LIBTOOL
>> sources or submitted to the master file maintainer and brought
>> in via a merge.
> 
> 
> It was my impression from Alexandre that he had already imported these 
> changes from the official sources into gcc's tree.  For some reason, they 
> weren't imported into the binutils/gdb tree at that time.

Ok, so now that the change is committed to the master repository, it can 
be committed locally.  Can the ``gcc-local'' bit be clarified - it is no 
longer gcc-local.  Rather it was an accelerated patch brought in from 
the master repository.

Andrew

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Alexandre Oliva]

On Nov 15, 2001, Andrew Cagney <ac131313@cygnus.com> wrote:

>>> Is there a reason for pulling in GCC's hacks rather than going to
>>> the official version per src/MAINTAINERS:
>>> ltconfig; ltmain.sh
>>> libtool: http://gnu.org
>>> Changes need to be done in tandem with the official LIBTOOL
>>> sources or submitted to the master file maintainer and brought
>>> in via a merge.
>> It was my impression from Alexandre that he had already imported
>> these changes from the official sources into gcc's tree.  For some
>> reason, they weren't imported into the binutils/gdb tree at that
>> time.

> Ok, so now that the change is committed to the master repository, it
> can be committed locally.  Can the ``gcc-local'' bit be clarified - it
> is no longer gcc-local.  Rather it was an accelerated patch brought in
> from the master repository.

Actually, it was indeed gcc local.  GCC used to import it from a
libtool branch, but the libtool branch was declared dead and merged
into libtool mainline along with major reworking.  So much that I
didn't feel confident about importing it entirely into GCC just
before some 3.0.x release.  So, we got patches into GCC, as long as
similar fixes went into libtool.

Eventually, I'll be confident enough with libtool CVS mainline (after
doing some testing with it) that I'll import it into GCC and src.
Meanwhile, we can live on with what we have now, i.e., a stable
snapshot of a libtool CVS branch plus a few patches that didn't make
it to the branch before it was terminated.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> Changes need to be done in tandem with the official LIBTOOL
> sources or submitted to the master file maintainer and brought
> in via a merge.

Indeed.  I went through this procedure.  Before I submitted this change to gcc,
I submitted it to libtool and it was accepted in the mainline there.

From the libtool ChangeLog:

  2001-07-09  Robert Boehne  <rboehne@ricardo-us.com>

        From Michael Elizabeth Chastain <chastain@cygnus.com>:
        * libtool.m4 (AC_LIBTOOL_SYS_MAX_CMD_LEN):  Set max_cmd_len
        to a maximum of 512Kb, as it seems some HPUX 11.0 systems
        have trouble with 1MB.

Alexandre Oliva asked me to mark this change as "gcc-local" in the
gcc sources; I don't remember the reasoning behind this.

You might want to run through your import procedure and check that
it yields the fixed ltconfig now.  I'm getting my libtool from
"cvs -z3 -d :pserver:anoncvs@subversions.gnu.org/cvsroot/libtool co libtool"
which I believe is the official source.

Michael C

Re: [Patch] updated ltcf-*.sh, ltconfig, ltmain.sh

[Alexandre Oliva]

On Nov 14, 2001, Michael Elizabeth Chastain <mec@shout.net> wrote:

> Alexandre Oliva asked me to mark this change as "gcc-local" in the
> gcc sources; I don't remember the reasoning behind this.

The reason was that libtool had already diverged significantly from
what we had been using, and the libtool branch from which I had been
doing imports into gcc and src were regarded as dead by other libtool
folks.  I felt importing libtool mainline was inappropriate for GCC
3.0, and then, when the same problems were reported against GCC
mainline, I still hadn't had time to test it against libtool mainline,
so I went ahead and just merged the known-to-work files from GCC 3.0,
but failed to apply the same patch in src.  Now Jeff ran into the same
problem using src's top level, so I suggested him to just merge these
files.

I shall look into doing a proper merge from libtool, but I haven't had
time to even open my libtool e-mail folders in the past few months :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me