On Tue, Oct 10, 2017 at 11:20 AM, Nick Clifton <ni...@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...
