Commit: Update libiberty

[Richard Earnshaw (foss)]

On 08/01/2026 17:43, Maciej W. Rozycki wrote:
> On Thu, 8 Jan 2026, Nick Clifton wrote:
> 
>>> I can reproduce the failure locally:
>>>      configure.ac:161: error: m4_defn: undefined macro: GCC_AC_FUNC_MMAP
>>
>> It seems that we have some local changes to the libiberty sources of which
>> I was not aware.  After a little research I found the problem and so I have
>> applied commit a502e852fd2 to restore the changes from commit
>> 219822fd5db6305592b45677a3b38c02b523360e
> 
>  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?  Or would it make sense to work towards re-establishing 
> our old quality standard instead?
> 
>   Maciej

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

R.