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? > >> 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
