Patch to update libtool in GCC and Src trees

[Paolo Bonzini]

libtool@cwilson.fastmail.fm wrote:
> I thought the goal (policy?) was
> for the src and gcc trees to use only:
>  (1) official released versions of external tools/libraries
>  (2) or imported snapshots of said external tools/libraries taken
>  directly from those external project's development tree

Sure -- my proposal was only a temporary measure before importing 
top-of-tree libtool.  Steve said it was a one liner, but I thought it 
was one line compared to gcc/src, not compared to the original checkin!

> Perhaps Steve's current effort will be the last libtool import until
> libtool releases its next major version (aka 2.0 or 2.2 or whatever they
> decide to call it).  Or maybe there will be future re-imports from
> libtool CVS every few months or so: annoying, but not especially trying
> if they are relatively infrequent.  Especially as I expect such
> re-imports will be much less disruptive than THIS major change. 

I would expect relatively frequent (once per month?) but absolutely 
non-disruptive imports until the next libtool release; then, we should 
track the corresponding stable releases.

To reassure Jeff, I will remark that the conversion to 2.59/1.9 actually 
started as 2.54/1.6, and there were basically no disruptive changes in 
autoconf/automake during these releases (2.54 to 2.59 for autoconf, 1.6 
to 1.9 for automake).  And this libtool change is basically the 
completion of the complex transition to autoconf 2.59 -- which explains 
the trouble it's causing.

My only request to the libtool team, is to keep it working with 2.59 for 
a while and not require 2.61, because that will be another relatively 
complex update for gcc/src (though not as much as from 2.13 to 2.59).

> Or re-import libtool "too often" for your liking

Please complain if this is the case, but I hope that the libtool guys 
also don't do any disruptive changes for well-supported targets 
(i686-linux) when the first stable release in years is in sight...

> , or litter <toplevel>/m4/ with a bunch of "fixes" to compensate
> for shortcomings of the carved-in-stone ac-2.59/am-1.9.6. 

So far, we have only one bugfix in 2.60+ that needs to be worked around 
because we use 2.59, and I'm confident very few (if any) will be needed.

Paolo, who would prefer autoconf maintainers to update major version 
numbers more eagerly!