Roland Mainz writes: > > 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 ?
If they do that -- and I really don't see that they do -- then it's a bug. Please file a bug against it, and be specific about where the problem occurs. The fact that some other software may have some bugs doesn't mean that new software attempting to integrate gets a free pass on the same bugs. It's not a matter of "allowed" or "disallowed" or of having special privileges for certain classes of software; it's a matter of _not_ integrating new design flaws into the system. > 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))). Again, if you see problems in the system, then file bugs. Don't replicate errors. > 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). I don't think that helps. There's still no guarantee that libc.so.1 -- which you'll pick up from this LD_LIBRARY_PATH -- or any of the other libraries you're using can actually run on the current system. There's no way to know, so this is just a ticking time bomb for maintainers. > > 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. Then I think this is something that will need to be addressed. One way to do it is to limit those shell scripts to a subset of the language that works with /usr/bin/ksh. Surely, if ksh93 is to replace /usr/bin/ksh some day, there must be some common subset. Another way to do it would be to do a native compilation of ksh93 as part of the build process alongside the target $ROOT compilation. Yes, that would likely be pretty wasteful. It'd be a shame to have to do that. Still another way to do it would be to have some ksh93 package added as part of the common build environment. You could create a package that delivers to (say) /opt/ksh and includes a copy of ksh93 compiled on some suitably old system so that it's known to work everywhere. The build process would then change to have /opt/ksh/bin on the $PATH, after /usr/bin so that once ksh93 is found on normal build machines, the package can be ignored. Hacking around with LD_LIBRARY_PATH, though, isn't an acceptable answer. It's ugly and fragile. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
