On Fri, 4 Apr 1997, Chip Salzenberg wrote:
> According to Olaf Seibert:
> > In this report I am using the shared perl library, libperl.so.3.97.
> >
> > When building miniperl, it is linked with libperl.so.3.97 instead of
> > -lperl. This slightly confuses NetBSD's shared loader. When miniperl
> > is run from a directory where libperl.so.3.97 is not present, it
> > will fail to start.
> >
> > Fix: I think this should do it: Change in the Makefile
> > LLIBPERL= $(LIBPERL)
> > to
> > LLIBPERL= -lperl
>
> Porters? I'm a bit out of my depth with this, since I'm not sure
> of what's portable with dynamic loading and what isn't.
My paranoid fear is the following: Suppose you already have
perl5.003_97 installed somewhere and it has a corresponding
libperl.so.3.97 installed in the appropriate directory. Now suppose
you're rebuiding perl5.003_97 (e.g. to test a patch or whatever) and
your new ./perl is linked with the moral equivalent of
LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH
cc -o perl -R $archlib -lperl [...]
Now, when you're down in the t/ library running your tests, and miniperl
gets called, which libperl.so.3.97 do you get -- the new one found via
LD_LIBRARY_PATH or the old one found via the -R directive?
(This is very similar to the shared libperl/debugging problem discussed in
the INSTALL file.)
I don't think any solution is bulletproof. I suspect that the suggested
change probably won't make matters any worse, but I'm wary at this stage
(gee, that's a suprise from me:-)
Instead, I think the following should probably be safe:
p5p-msgid: Pine.SOL.3.95q.
970404124326.647K-100000@fractal.lafayette.edu
private-msgid: Pine.SOL.3.95q.
970404124326.647K-100000@fractal.lafayette.ed