Mike Kupfer wrote: > Roland> Are the test failures always the same ? > > Yes and no. The failure with path.sh was with BUILD_KSH93_AS_BINKSH=1. > I only tried it once.
Can you try it again, preferably with B37 to avoid we're seeing any "ghost" bugs caused by any libc/libsocket/libnsl/libm/etc.-flag day or other kind of disturbance ? > The failure with io.sh is with > BUILD_KSH93_AS_BINKSH=0 and is repeatable. See below... > Roland> # Note that "builtins.sh" is allowed to fail until upstream fixes > Roland> # -- snip -- > Roland> # "ld.so.1: ksh: fatal: relocation error: file > Roland> xxx/usr/src/cmd/ksh/i386/ksh: symbol sh_waitnotify: > Roland> # referenced symbol not found > Roland> ../../../lib/libshell/common/tests/builtins.sh: line 313: 28473: > Roland> # Killed builtins.sh[314]: "name=value exec -c ..." not > working" > Roland> # -- snip -- > > Okay, this will have to be addressed prior to putback BTW: I reported this issue in https://mailman.research.att.com/pipermail/ast-users/2006q3/001085.html to upstream. > either get the > fix from upstream, or skip the test. Erm... the test is currently treated in a way which makes a failure non-fatal. Isn't this enougth ? > We might even want to change > cmd/ksh/Makefile.com so that "all" doesn't depend on "testshell". Umpf... only if we can't resolve the failures this week, Ok ? I would be very unhappy with loosing the tests as part of the default build because this could be a very usefull instrument to catch worse things (like hiccups in libc&co.) very early... > Roland> The failures in "path.sh" and "io.sh" are new for me... how does > Roland> your ${PATH} look like ? > > athyra--proto2$ echo $PATH > /opt/onbld/bin:/opt/onbld/bin/sparc:/opt/SUNWspro/bin:/usr/ccs/bin:/usr/bin:/usr/sbin:/usr/sfw/bin:. Mhhh... this should work... In http://polaris.blastwave.org/changeset/325 I changed the way how ${PATH} is created - instead of adding some stuff I now use a "fixed" string which only references content in $(ROOT)/ , however this is only half-functional (at least in theory, to keep it working I added "/usr/bin" as the last element in ${PATH}) since usr/src/cmd/ksh/ is built in the mittle of the cmd/ commands and not at the end (of the list used in usr/src/cmd/Makefile)). One possible solution may be to move "ksh" to the end in "usr/src/cmd/Makefile", but I am not sure whether this is allowed since the list seems to be in alphabetical order... > Here's some more information: > > I hacked cmd/ksh/Makefile.com to only run io.sh, and I reran the test > with truss -f. truss shows that close1 is getting made mode 775, and it > looks like the echo command is getting written to it. But the exec is > indeed failing with ENOEXEC. > > If I hack io.sh to add a "#! /bin/ksh" line to the start of close1, the > test passes. Ok... I can now reproduce the problem. It only happens when the executable is not called "ksh" (like "ksh93" or "kshtentaclemonster") ... ;-( Anyway, I reported this to upstream as https://mailman.research.att.com/pipermail/ast-users/2006q3/001089.html and commited http://polaris.blastwave.org/changeset/330 to allow that "io.sh" fails until we figure out what's the best solution to fix this. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
