Samuel Thibault writes: > 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.
Right, that explains it. Anyway, we now have this fix in place. >> --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. Yes...I'll be cross building to create a 64bit Hurd VM, and only when that runs, we start native builds. >> 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. Strange. >> 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. Sure, but it would be nice if bash had a configure option, or even makefile flag to override it, instead of having to patch it. > We could however ask to downgrade it to 16384 (or even 4096 > to be safe). Ah yes, that too; not relying on the build host but choosing a low default that can be easily set during configure time would be nice. >> 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. Ok. Greetings, Janneke -- Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
