James Carlson wrote: > 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.
Would it be an option to put just libshell, libcmd, libpp, libdll and libast in a seperate directory and point ksh93 to use these libraries then ? This avoids the problem with libc (note that I forgot about libpp and it's implications in my original posting) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
