Re: Happy New Year 2024 & Freeze for the upcoming glibc 2.39 release

[Palmer Dabbelt <palmer@dabbelt.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

On Wed, 10 Jan 2024 17:10:11 PST (-0800), Palmer Dabbelt wrote:
> On Wed, 10 Jan 2024 12:33:51 PST (-0800), Jeff Law wrote:
>>
>>
>> On 1/10/24 11:38, Carlos O'Donell wrote:
>>
>>>>
>>>> (speaking not as a glibc maintainer [or even user!], but as someone
>>>> who aims for source compatibility where possible...) what's the status
>>>> of the riscv64 ifunc stuff?
>>>
>>> Adding Palmer and Jeff to TO: to see if we have an answer for this.
>> My recollection (from Cauldron) was that we were still waiting on a
>> final approval for the first ifunc'd mem* routine as Florian had raised
>> some correctness questions.  The idea was once Florian's correctness
>> questions were resolved we could use the knowledge to stamp out the
>> other routines that have implementations, but needed the right ifunc glue.
>>
>> I haven't had the time to follow glibc at all the last few months.  So
>> if there's been movement I wouldn't be aware of it.
>
> Evan has a patch set from this morning, I think it's ready to go.  I'd
> checked earlier this week too, but there were some comments.
>
> So I think we can just commit it, it's been a pretty long tail of small
> stuff.

We're both seeing some errors in build-many-glibcs, the compiler's build 
of glibc fails for i686-gnu and x86_64-gnu with

msg-destroy.c: In function ‘__mach_msg_destroy’:
msg-destroy.c:114:21: error: unknown type name ‘mach_port_name_inlined_t’; did you mean ‘mach_port_name_array_t’?
  114 |                     mach_port_name_inlined_t *inlined_ports = (mach_port_name_inlined_t *)addr;
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~
      |                     mach_port_name_array_t
msg-destroy.c:114:64: error: ‘mach_port_name_inlined_t’ undeclared (first use in this function); did you mean ‘mach_port_name_array_t’?
  114 |                     mach_port_name_inlined_t *inlined_ports = (mach_port_name_inlined_t *)addr;
      |                                                                ^~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                mach_port_name_array_t
msg-destroy.c:114:64: note: each undeclared identifier is reported only once for each function it appears in
msg-destroy.c:114:90: error: expected expression before ‘)’ token
  114 |                     mach_port_name_inlined_t *inlined_ports = (mach_port_name_inlined_t *)addr;
      |                                                                                          ^
msg-destroy.c:116:63: error: request for member ‘name’ in something not a structure or union
  116 |                         mach_msg_destroy_port(inlined_ports[i].name, name);
      |                                                               ^

I don't think that has anything to do with this patch set, but looks like it's
different than what folks are seeing over here

https://inbox.sourceware.org/libc-alpha/15a8d57-ccd6-7be5-8feb-7348dc2976f0@redhat.com/

Joseph pointed me to his test results on IRC

https://inbox.sourceware.org/libc-testresults/170493450738.1404407.10772674444944760670@tor.usersys.redhat.com/T/#u

and from reading that I think the problem might be that I have old 
gnumach/hurd versions.  It looks like I have master from last November 
(probably when I setup my build-many-glibcs tree).

    commit ccde19525333c38360684385c09cebd95a7b631f (HEAD -> master, origin/master, origin/HEAD)
    Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Date:   Tue Nov 7 00:24:54 2023 +0100
    
        mach/message.h: Fix C++98 build
    
        static_assert was introduced in C++11.

I'm trying another build with everything updated, hopefully that was the 
problem.