James Carlson wrote: > > Roland Mainz writes: > > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype004/usr/src/cmd/ksh/Makefile.com > > (Have there been any code reviews yet ... ?)
Some people looked ar various parts and suggested lots of changes - but the test run makefile target is in constant flux to hunt down the various bugs. > In that file, I see the following: > > export \ > SHELL="$(SRC)/cmd/ksh/$(CMDTRANSMACH)/ksh" \ > > LD_LIBRARY_PATH="$(ROOT)/usr/lib/$(MACH64):$(ROOT)/usr/lib/" ; \ > sync ; sync ; \ > > Besides the errant 'sync' invocations -- which don't belong here under > any circumstances, as they'll burden the build server for no reason -- ... the "sync ; sync" was added to figure out whether the build machine at Sun triggers some test suite issues via excessive paging (which wasn't the problem and that stuff will go away). > this use of LD_LIBRARY_PATH cannot stand. > > There's no guarantee whatsoever that the libraries and binaries found > in the proto area (under $ROOT) can or will actually run on the build > machine. In fact, we can guarantee that they WILL NOT run correctly > when there are libc/kernel flag days. Why is "perl" then allowed to run their compiled binary as part of the build ? It seems that this rule is bend very often during the build (I don't say it's Ok - but there are cases where it may be unavoidable (see below (I am not referring to the test suite here))). BTW: The ksh93 binaries build up to Nevada B48 (beyond that point we started to use |nanosleep()| which was previously in librt and now in libc ; the current binaries still run on Solaris 10 via putting LD_PRELOAD=librt.so.1 that the binary finds the required symbols in librt) were able to run on Solaris 10 - the code doesn't use much special features of the operating system as it is designed to be very portable and it is IMO unlikely to run into problems (as it surrived all flag days between Solaris 10 Update 1 and Nevada B48). > This is why, in the very, very rare cases where we must produce > binaries to be executed on the build system, we use a separate set of > targets and symbols. See NATIVE_CFLAGS, NATIVE_MACH, NATIVECC, and > the related bits in $SRC/Makefile.master. I think we have a problem then if we cannot use LD_LIBRARY_PATH - the code which generates the localisation catalogs is actually a set of ksh93 shell scripts. In theory we can avoid this after the putback since then the underlying build machines will have ksh93 installed after some Nevada build cycles... but for now it is almost unavoidable to run ksh93 as part of the build. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
