Re: shared lib compilation problem with miniperl5.003_97

Re: shared lib compilation problem with miniperl5.003_97

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