On Wed, 2021-01-27 at 18:26 +0000, Joseph Myers wrote: > On Wed, 27 Jan 2021, Richard Purdie wrote: > > > Thanks, I hadn't realised. The only two recipes we never autoreconf are > > binutils and gcc, instead we do some painful things to handle libtool > > issues so we get our libtool tweaks. It sounds like we should revisit > > that. I guess we were so used to not being about to do it we never > > looked back at it recently. > > > > Does that mean those projects will autoreconf more regularly if there > > are autotools releases? > > I'm likely to follow binutils+gdb in making autoconf/automake updates in > GCC.
Fair enough, I'll have to look into what our options are. I think the libtool mismatch issues are likely why we've not looked into this autoreconf. I know we have problems with libtool in both binutils and gcc which mean we have heavy patches for that. > libtool updates are trickier, and probably more relevant to GCC than to > binutils+gdb. GCC is using a 2009 version of libtool (reportedly commit > 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622) with lots of local patches, some > of which may not be upstream (libtool upstream isn't very active), and > different interpretations of --with-sysroot mean that updating libtool in > GCC would also require reverting libtool commit > 3334f7ed5851ef1e96b052f2984c4acdbf39e20c in the new version of the libtool > files used in GCC (in addition to making sure that any other > not-yet-upstream local libtool patches are preserved). I think this is the key part of the problem, we carry a patch to rename the option in libtool due to the conflicts the libtool naming caused. We do have a queue of libtool patches, I'd love to see a way of reconciling the sysroot option issue with libtool upstream. Its a chicken and egg problem since we're less likely to spend time on sending the patches if we aren't likely to see them at least get into source control. I guess I'm diverging for the autoconf list now though! Cheers, Richard
