Glibc build failure with /bin/sh -> /bin/dash

Matthew Burgess matthew at linuxfromscratch.org
Wed Feb 14 15:10:20 PST 2007


Hi guys.

Sorry for starting a new thread but I wasn't subscribed before!

As far as I understand it, all the scripts that jhalfs generates use 
#!/bin/bash.  I'm fine with this, as it's obviously the easiest way to get 
around the whole "glibc only builds under bash" stupidity.

As you know, currently jhalfs applies a workaround of 
passing "SHELL=/bin/bash" to `make' so that progressbar.sh and the unpack 
commands, which contain bashisms, work properly.  The problem I have with 
this is that by doing this, the environment is different to that which is 
explicitly defined in the LFS book, hence jhalfs diverges from the commands 
in LFS and therefore can't be trusted as a mechanism to test the book out 
with.  If it hadn't have been setting SHELL, I'd have seen the whole glibc 
vs. dash problem first-hand and could have gotten the book fixed up sooner.

So, where do we go from here?  Obviously I'd love to be able to use jhalfs as 
an automated way of testing the commands in the LFS book, according to the 
environment we explicitly configure in the book.  To do that, and to maintain 
our ability to build on hosts that have a /bin/sh != /bin/bash I'll propose 
the following:

1) Keep the #!/bin/bash shebang lines in the chapter05 scripts.  They can be 
set to  #!/bin/sh in chapter06 onwards, though if that complicates jhalfs' 
code too much then having them all at #!/bin/bash is fine, obviously.

2) Remove setting "SHELL=/bin/bash" on the `make' lines so that when the shell 
scripts are invoked they are done so with the same environment as if the 
build was being done by hand following the LFS book.

3) Fix up the progressbar.sh script to not use any bash-specific constructs.  
I've not looked at it yet, so don't know how much of a chore that is.  I did 
look at the unpack target in 'makefile-functions' and I tested it without 
passing SHELL=/bin/bash and it seems to work fine.  Was this what you were 
referring to in your post to lfs-dev, Manuel?

Thanks,

Matt.




More information about the alfs-discuss mailing list