James Carlson wrote: > 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.
I disagree that this is a bug or "design flaw". The matching code (AFAIK called "miniperl") many many times during the build process and AFAIK that should be a legal prodecure. otherwise it will likely be tricky to have "perl" in the build system at all. [snip] > > 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. See below... > > > 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. Erm, I am not sure whether this is possible via ksh88/bash/sh. ksh93 has some advanched features like discipline functions, associative arrays or floating-point support which are VERY hard to emulate in older shells. The only other option would be to rewrite those tools in "perl" > 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. Grumpf... xx@@@!!!... ;-( The new dependicy would generate a "flag day" which should IMO be avoided at all costs under any imagineable/possible/whatever circumstances (e.g. if komodo dragons start to invate the US mainland, doomsday etc.) as it would endanger the backport to Solaris 10. We've been trying to avoid such a thing very hard over the the last few months and even ripp-out features which may generate such a problem. And I am not even convinced that this is neccesary - we've been testing this now for nine months in our Subversion tree and neither our or any of the Sun build machines ever showed such a problem. I don't say it can't happen, but it is unlikely to strike between the putback and the next ksh93 update in OS/Net which will then remove the useage of LD_LIBRARY_PATH... at least the statistics are on my side... :-) Would it be possible to create a wrapper script which only loads libshell, libcmd, libdll and libast into a temporary directory and let "ksh93" use these libraries ? That would avoid the problem with libc.so.1 completely... > Hacking around with LD_LIBRARY_PATH, though, isn't an acceptable > answer. It's ugly and fragile. As I said for the localisation scripts LD_LIBRARY_PATH is only needd temporarily until all underlying built systems have been updated. I am strongly opposed to accept an solution which generates a "flag day" by forcing everyone to install a statically-build ksh93 manually first and then get rid of it a few Nevada release cycles later. That's an extremely wastefull solution... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
