Re: MiNT vs GNU configure

[Joris.Welkenhuysen@uz.kuleuven.ac.be (Joris Welkenhuysen)]

>>>>>> "Chris" == Chris Herborth <cherborth@semprini.waterloo-rdp.on.ca> writes:
>
>Chris> Looking in configure, config.status is written with a statement
>Chris> that pulls lines from configure up to a EOF line, which is a
>Chris> fair number of lines down.  Is bash (and /bin/sh) halting
>Chris> because there's a buffer that's too small?  The bash that's
>Chris> working on configure is set to 'Wait' if I check with top, but
>Chris> it never wakes up.
>
>
>It sounds very much like the dreaded blocking fork problem.
>
> One probably also could fix the pipe
>buffer size and recompile the kernel. I would guess that a quite
>moderate size would fix the problem for the majority of such scripts.
>
>
>------------------------------------------------------------------------------
>Christian Lynbech               | Hit the philistines three times over the
>office: R0.33 (phone: 3217)     | head with the Elisp reference manual.
>email: lynbech@daimi.aau.dk     |        - petonic@hal.com (Michael A. Petonic)
>------------------------------------------------------------------------------

Ok, I'm writing this based on my memory : my TT with all of my sources is
at home.

I'm assuming that the bash version you are using is based on the latest GNU
release (1.14.1 ?).
I once did a port of that version to mint, had the same problems but have
resolved all of them.
My version is running for a couple of months now and I have executed many
GNU config scripts
with it, never having any problems.

The problem that is mentioned above is related to the blocking fork, but
really is a bug in
bash. When the configure script writes the config.status file, it uses a
here-document
containing command substitutions, something like this :

cat <<! >config.status
`basename ...`
<!

bash forks off a process to execute basename and copies the output to the
config.status file.
It also waits for the SIGCHLD signal so it can delete the job from it's
internal tables or something.
The bug in bash is that the signal intercept routine is set up after the
fork, and under race
conditions (even on a regular Unix box) this can lead to a lost signal and
deadlock. Using mint,
this race condition is bound to happen since the parent remains blocked in
the fork system call,
and only revives when the child is dead and the signal has been generated
and lost.

Last week or so this same discussion was held on this forum. Andreas Schwab
(I think he did
the port of the publicly available bash for mint) asked me then to send him
the changes I made to
bash,  which I did. I could make my own port (or the diffs) available on
the net, but I think it's better
if there would only be one `real' mint bash. So Andreas, if you read this,
let me know what to do !
I propose that the one with the better internet connectivity takes
initiative (that being you of
course :-)

Joris.