On November 16, 2024 10:13:22 PM GMT+02:00, Samuel Thibault <samuel.thiba...@gnu.org> wrote: >jann...@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit: >> Samuel Thibault writes: >> >> > jann...@gnu.org, le sam. 16 nov. 2024 17:33:08 +0100, a ecrit: >> >> >> Okay, so Guix hasn't been using >> >> >> >> <https://salsa.debian.org/glibc-team/glibc/-/blob/25a0a47767fe7dc5151eb36afaade17218728efe/debian/patches/hurd-i386/local-static_pthread_setcancelstate.diff> >> >> >> >> which didn't seem to be a problem before / with 32bit. >> > >> > I'm surprised it wouldn't be a problem on 32bit too. >> >> Hmm...while our bootstrap-glibc was updated 20200326, the static >> binaries are from 20200326. We were using glibc-2.31 at that time. > >Ok, so the ptf issue wasn't there. > >> > We can probably prioritize moving the __pthread_setcancelstate function >> > from htl to glibc, so this patch gets not needed any more. >> >> That would be nice. > >Guy, could you make it a priority in your symbol list?
No problem. I will do that. > >> >> Meanwhile, I found another hang in bash when it calls WAITPID. >> > >> > That doesn't ring a bell either. Where does it hang exactly? >> >> Found it: in bash's redir.c. During [cross-]compilitation, >> builtins/pipesise.h: >> >> --8<---------------cut here---------------start------------->8--- >> /* >> * pipesize.h >> * >> * This file is automatically generated by psize.sh >> * Do not edit! >> */ >> >> #define PIPESIZE 65536 >> --8<---------------cut here---------------end--------------->8--- > >Ah, you are cross-building. I did encounter this one while bootstrapping >debian hurd-amd64 indeed, but got very different symptoms. > >> Using a hack during cross-build to use 16384 fixes the problem. I'm >> wondering why this never came up on the 32bit Hurd, does that match the >> Linux pipe size (65536)? > >No, not either. > >> If so should this issue still be reported to bash upstream, > >The problem is that it's not really solvable: this can only be detected >at run time. We could however ask to downgrade it to 16384 (or even 4096 >to be safe). > >> or will the 64bit Hurd also match Linux pipe size in the >> future? > >We could increase it but sooner or later Linux would increase it and >bash possibly follow. Better just make bash take a safe default. > >Samuel > Hello,
