This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Update top level libtool files
On Tue, Oct 10, 2017 at 11:20 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Joseph,
>
>> As per previous discussions on the issue: it's necessary to revert libtool
>> commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c, see
>> <https://gcc.gnu.org/ml/gcc-patches/2011-01/msg00520.html>.
>
> OK - thanks for that pointer.
>
>> I do not know
>> if there are other local libtool changes that are not in version 2.4.6; it
>> would be necessary to check all differences from 2.2.7a to determine
>> whether any need to be re-applied to 2.4.6.
>
> *sigh* It seems that 2.2.7a was not an official release. At least I could
> not find a tarball for that specific version on the ftp.gnu.org/libtool archive.
> (There is a 2.2.6b release and a 2.2.8 release but no 2.2.7<anything>). So it
> looks like we have been using a modified set of sources for a long time now.
>
> Maybe I would be better off not rocking the boat, and just submit the Fedora
> sys_path patch for consideration instead...
>
>
>> For that matter, these trees are also using very old autoconf and automake
>> versions and using the current versions of those (2.69 and 1.15.1) would
>> be a good idea as well. Hopefully version dependencies are loose enough
>> that it's possible to update one tool at a time (so update libtool without
>> needing to update autoconf or automake at the same time).
>
> Oh gosh - I would love to see that done. But the last time I tried I ended
> up going down a rabbit hole of autoconf/automake problems that just never
> ended. So I gave up. :-( Maybe someone with more autoconf-fu than me will
> have a go one day though.
>
> Cheers
> Nick
>
I updated my fork of binutils/gdb (which shares a toplevel with gcc)
to use autoconf 2.69 and automake 1.15 instead of the current
versions, and it usually works for my usecase, but I think there's
still issues with it and I probably broke stuff in the process, so I'd
be afraid of making similar mistakes if I tried to do the same update
for gcc...