Roland Mainz writes: > > 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.
If you look carefully, I think you'll see that miniperl isn't forced to use libc.so.1 from $ROOT. In any event, staring at the Perl sources -- whether they're right or wrong on this point -- is not the right answer. Several ON libraries (particularly libc.so.1, but others as well) have interdependencies with the kernel. This means that you _cannot_ expect a newly built libc.so.1 to work on the running system unless the running system is identical to the code being built -- an impossibility for build machines. Thus, using LD_LIBRARY_PATH to pick up libraries under $ROOT is the wrong answer. This is also why they're included in the kernel update patches. > > 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" If you're really using all of those features and they're not available in ksh, then this option won't fit. Pick another. > > 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" Indeed, it would. Why is that a problem? > 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. Nonsense. It's a dependency for build machines. These are not uncommon. > 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... :-) I'm trying to restrain myself from using strong language here. A plan based on mere "luck" is utterly unacceptable and indefensible. If you cannot find a way around this, then you can expect to hear about it during your C-team review. > 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... That's much better, but still pretty horrible. Future flag days that involve header files will likely cause gatelings pain -- because of your project. > > 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... Please talk with the gatekeepers before making such a decision. I think you are poorly informed about the relative merits of a flag day over proper design. -- 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
