Commit: Update libiberty

[Nick Clifton]

Hi Guys,


>>>   Please note however that in top-level MAINTAINERS we have this:
>>>
>>> intl/; config.rhost; libiberty/; libiberty's part of include/;
>>> compile; depcomp; install-sh; missing; ylwrap; config/; libbacktrace
>>> 	gcc: http://gcc.gnu.org
>>> 	Changes need to be done in tandem with the official GCC
>>> 	sources or submitted to the master file maintainer and brought
>>> 	in via a merge.  Note: approved patches in gcc's libiberty or
>>> 	intl are automatically approved in this libiberty and intl also;
>>> 	feel free to merge them yourself if needed sooner than the next
>>> 	merge.  Otherwise, changes are automatically merged, usually
>>> 	within a day.
>>>
>>> Do we need to update the statement to match reality, i.e. that changes
>>> aren't automatically merged anymore and that the two copies have diverged
>>> from each other?

No, we definitely want to avoid that.

>>>  Or would it make sense to work towards re-establishing
>>> our old quality standard instead?

Yes, that would be preferred.

>> Please don't let them diverge.  That breaks setting up a single source tree build for the toolchain.

Agreed.

> Indeed it has been necessary to apply some care when wanting to do that. It
> would really be nice if the delta could be eliminated, yet I have a vague
> recollection that this might be one of H.J.'s gems which gcc didn't like.

It would appear that way.  I also note that the original patch that caused the
divergence was applied 9 Apr, 2024, so it would look like gcc is not going to
adopt this solution.

The patch however does note that it is working around a problem in autoconf
that was fixed way back in 5 Feb, 2016.  So the real issue is that we need to
switch to using autoconf 2.70 or later.

I would definitely like to switch to a newer version of autoconf.  But I do
not want to do it right before branching for a new release.  So I think that
for now:

   1. We leave in H.J.'s patch - it fixes a real problem that prevents
      the binutils from being built with -fsanitize=address,undefined.

   2. After the branch is made some kind soul offers to try out building
      the configure and makefiles with newer versions of the auto tools,
      and fixing any problems that arise.

Or is this too controversial ?

Cheers
   Nick