Commit: Update libiberty

[Jan Beulich]

On 09.01.2026 15:45, Richard Earnshaw (foss) wrote:
> 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?
> 
> Please don't let them diverge.  That breaks setting up a single source tree build for the toolchain.

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.

Jan