Glenn Fowler wrote: > On Fri, 17 Nov 2006 04:20:02 +0100 Roland Mainz wrote: > > Yes... IMO the test suite is mission-critical (except the one issue we > > have with the LD_LIBRARY_PATH thing - but that's nothing serious). We > > wouldn't be better than the old Solaris /usr/bin/ksh which lacked this > > "safeguard" and was hacked to something which is no longer compatible to > > anything (like the original ksh88i or it's siblings on other Unix > > versions) except itself. > > getopts is getting close -- should be ok by tomorrow > > refresh me on the "LD_LIBRARY_PATH thing" > ast $(getconf LIBPATH) addresses local "LD_LIBRARY_PATH" name permutations
See http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype004/usr/src/cmd/ksh/Makefile.com One test in "builtins.sh" fails like this: -- snip -- ld.so.1: ksh: fatal: libshell.so.1: open failed: No such file or directory ../../../lib/libshell/common/tests/builtins.sh: line 313: 8407: Killed builtins.sh[314]: "name=value exec -c ..." not working -- snip -- This is a result of the problem that the OS/Net build installs all files in a "proto area" where the env variable ${ROOT} points to the filesystem base e.g. "/"). To run the tests we set LD_LIBRARY_PATH that the tets suite properly finds libshell.so.1/libcmd.so.1/libast.so.1 etc. and all the other libraries. This works except for this test because it clears the environment which includes LD_LIBRARY_PATH. The following invocation of another ksh93 instance then fails because the underlying build system has no libshell.so.1 nor any of the other libraries (getconf won't help since it doesn't pass the value of LD_LIBRARY_PATH through). I've posted a patch to fix the problem in July (see http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-July/000524.html) ... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
