RFC: Update top level libtool files

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Update top level libtool files

Nick Clifton
Hi Guys,

  I would like to update the top level libtool files (libtool.m4,
  ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by
  gcc, gdb and binutils.  Currently we have version 2.2.7a installed in
  the source trees and I would like to switch to the latest official
  version: 2.4.6.

  The motivation for doing this is an attempt to reduce the number of
  patches being carried round by the Fedora binutils releases.
  Currently one of the patches there is to fix a bug in the 2.2.7a
  libtool which causes it to select /lib and /usr/lib as the system
  library search paths even for 64-bit hosts.  Rather than just bring
  this patch into the sources however, I thought that it would be better
  to upgrade to the latest official libtool release and use that
  instead.

  I have successfully run an x86_64 gcc bootstrap, built and tested lots
  of different binutils configurations, and built and run an x86_64 gdb.
  One thing that worries me though, is why hasn't this been done before?
  Ie is there a special reason for staying with the old 2.2.7a libtool ?
  If not, then does anyone object to my upgrading the gcc, gdb and
  binutils mainline sources ?
 
Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

Markus Trippelsdorf
On 2017.10.10 at 12:45 +0100, Nick Clifton wrote:

> Hi Guys,
>
>   I would like to update the top level libtool files (libtool.m4,
>   ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by
>   gcc, gdb and binutils.  Currently we have version 2.2.7a installed in
>   the source trees and I would like to switch to the latest official
>   version: 2.4.6.
>
>   The motivation for doing this is an attempt to reduce the number of
>   patches being carried round by the Fedora binutils releases.
>   Currently one of the patches there is to fix a bug in the 2.2.7a
>   libtool which causes it to select /lib and /usr/lib as the system
>   library search paths even for 64-bit hosts.  Rather than just bring
>   this patch into the sources however, I thought that it would be better
>   to upgrade to the latest official libtool release and use that
>   instead.
>
>   I have successfully run an x86_64 gcc bootstrap, built and tested lots
>   of different binutils configurations, and built and run an x86_64 gdb.
>   One thing that worries me though, is why hasn't this been done before?
>   Ie is there a special reason for staying with the old 2.2.7a libtool ?
>   If not, then does anyone object to my upgrading the gcc, gdb and
>   binutils mainline sources ?

Last time I've looked in 2011, libtool's "with_sysroot" was not
compatible with gcc's. So a naive copy doesn't work. But reverting
commit 3334f7ed5851ef1 in libtool before copying should work.

--
Markus
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

Joseph Myers
In reply to this post by Nick Clifton
On Tue, 10 Oct 2017, Nick Clifton wrote:

> Hi Guys,
>
>   I would like to update the top level libtool files (libtool.m4,
>   ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by
>   gcc, gdb and binutils.  Currently we have version 2.2.7a installed in
>   the source trees and I would like to switch to the latest official
>   version: 2.4.6.

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>.  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.

>   I have successfully run an x86_64 gcc bootstrap, built and tested lots
>   of different binutils configurations, and built and run an x86_64 gdb.

Testing cross compilers, including Canadian crosses, would be important as
well.

>   One thing that worries me though, is why hasn't this been done before?
>   Ie is there a special reason for staying with the old 2.2.7a libtool ?
>   If not, then does anyone object to my upgrading the gcc, gdb and
>   binutils mainline sources ?

Given appropriate testing and checks of local libtool changes, I think
such updates are a good idea.  (As, for that matter, would be resyncing
the toplevel configure/build code in the newlib-cygwin repository with
that in GCC and binutils-gdb - but I don't know if newlib-cygwin has any
unique local patches not in the other repositories, and given the
out-of-sync nature at present I don't think such a resync can be required
as part of an update in GCC and binutils-gdb.)

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).

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

David Edelsohn-3
In reply to this post by Nick Clifton
On Tue, Oct 10, 2017 at 7:45 AM, Nick Clifton <[hidden email]> wrote:

> Hi Guys,
>
>   I would like to update the top level libtool files (libtool.m4,
>   ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by
>   gcc, gdb and binutils.  Currently we have version 2.2.7a installed in
>   the source trees and I would like to switch to the latest official
>   version: 2.4.6.
>
>   The motivation for doing this is an attempt to reduce the number of
>   patches being carried round by the Fedora binutils releases.
>   Currently one of the patches there is to fix a bug in the 2.2.7a
>   libtool which causes it to select /lib and /usr/lib as the system
>   library search paths even for 64-bit hosts.  Rather than just bring
>   this patch into the sources however, I thought that it would be better
>   to upgrade to the latest official libtool release and use that
>   instead.
>
>   I have successfully run an x86_64 gcc bootstrap, built and tested lots
>   of different binutils configurations, and built and run an x86_64 gdb.
>   One thing that worries me though, is why hasn't this been done before?
>   Ie is there a special reason for staying with the old 2.2.7a libtool ?
>   If not, then does anyone object to my upgrading the gcc, gdb and
>   binutils mainline sources ?

AIX is another target that will need to be tested carefully for such a change.

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

Nick Clifton
In reply to this post by Joseph Myers
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

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

Joseph Myers
On Tue, 10 Oct 2017, Nick Clifton wrote:

> > 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.

Well, it looks like the update from upstream was

  r155012 | rwild | 2009-12-05 17:18:53 +0000 (Sat, 05 Dec 2009) | 113 lines

  Sync from git Libtool and regenerate.

so looking for relevant libtool commits around that time might help
identify the one that was used.  My guess is that

commit ef32f487d746dbcdc00c2c357ebe3cf2a68d8a28
Author: Ralf Wildenhues <[hidden email]>
Date:   Tue Nov 24 12:22:13 2009 +0100

    Enable symbol versioning with the GNU gold linker.

is the libtool commit you should be comparing libtool files with to
identify local changes.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Update top level libtool files

Eric Gallager
In reply to this post by Nick Clifton
On Tue, Oct 10, 2017 at 11:20 AM, Nick Clifton <[hidden email]> 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...