[parisc-linux] glibc build fails / bash bug

[parisc-linux] glibc build fails / bash bug

[Randolph Chung]

Bdale, taggart and I have been looking at trying to build glibc on hppa
from Debian's sources.  What we saw was that it looks like a lot of the 
syscalls were not being reocognized as such by one part of the build, so 
it tries to build things from the sysdeps/generic directory and fails.

After a lot of digging, I *think* what is at fault is actually bash. It
looks like during the build, a shell script (make-syscalls.sh) parses
through syscalls.list to generate syscall stubs that are needed for the
build to happen correctly, but these are not being generated. What it 
boils down to, I think, is this:

(on hppa - bdale's J5K)
=============================
tausq@j5k:/space/tausq $ bash --version
GNU bash, version 2.04.0(1)-release (hppa-unknown-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.
tausq@j5k:/space/tausq $ dpkg -l |grep bash
ii  bash           2.04-7         The GNU Bourne Again SHell
tausq@j5k:/space/tausq $ cat test.sh
#!/bin/sh

echo "1 2 3 4 5
a b c d e 
" | 
while read a b c d e; do
        echo $a $b $c $d $e
done
tausq@j5k:/space/tausq $ /bin/bash test.sh
1 2 3 4 5
=============================
(on other archs, tested with i386 and sparc)
samwise[11:06] ~% bash --version    
GNU bash, version 2.04.0(1)-release (i386-pc-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.
samwise[11:06] ~% dpkg -l |grep bash
ii  bash           2.04-7         The GNU Bourne Again SHell
samwise[11:06] ~% /bin/bash test.sh
1 2 3 4 5
a b c d e


This causes the parsing routines to die quite miserably....

Anyone feel like trying to fix this? :-)

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] glibc build fails / bash bug

[bame]

= After a lot of digging, I *think* what is at fault is actually bash.

Bash has a bunch of 'set' options, some shell variables, and probably
some compile-time configure options, which affect its behavior, so I'd
compare all those.  One possibility is that the bash configure script on
hppa configures bash to be more like Posix, since that's what hp-ux shell
users expect.

The construct in question:

	echo "a b c
		1 2 3" | while read x1 x2 x3

*depends* on the way echo breaks or doesn't break lines, and the way
read parses them.  Often scripts like that also depend on whether
the shell actually makes a new subprocess for the 'while' or it doesn't,
because that determines whether variables set in the loop will still be
set on exit from the loop.  While I didn't find a way to make the
construction fail, a safer method (when you get a choice) is to use 'set':

	set -- a b c \
		1 2 3

	while [ $# != 0 ]
	do
	    echo $1 $2 $3
	    shift 3
	done

	-Paul "too much shell programming" Bame