bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] buildi


From: Samuel Thibault
Subject: Re: static tar-1.34 hanging on warning/error [WAS: SOLVED [cross] building gdb for the 64bit Hurd?]
Date: Sat, 16 Nov 2024 21:13:22 +0100

janneke@gnu.org, le sam. 16 nov. 2024 20:47:40 +0100, a ecrit:
> Samuel Thibault writes:
> 
> > janneke@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]