Re: [Plplot-devel] decoupling drivers from libplplot

[Alan W. I. <ir...@be...>]

On Mon, 2 Sep 2002, Geoffrey Furnish wrote:

> Okay, well, I bit the bullet, and implemented a large part of the env
> handle object thing that I've discussed recently, and previously.
>
> So I went to test it, and as the first step, I tried to run the ps
> driver inside a java example (this is with dyn drivers), but without
> first changing ps.c to eliminate the direct linkage to plPhyRot.
>
> Curiously, it ran without difficulty.

I just tried replacing

gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o -L. -lplplotd

with

gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o

and it didn't generate any errors at all from either python or java.  But
then I recalled the dlopen code tries both the plplot/tmp/drivers location
and installed location for something valid.  So I removed my installed
version (you should do this as well), and then both python and java fail to
work with the second form, but work fine with the first form.

>
> Just to confirm:  Alan, you're using a JDK less than 1.4.0, and if you
> drop the -lplplot when linking psd_drv.so, then you can't run the ps
> driver inside a java example, right?

Yep, I was using jdk1.2.2 with the above example.  But I think that might be
a red herring.  Try again with the above shortened link line with no
installed version of plplot, and I suspect you will also see errors with
both java and python.

BTW, I thought your "possible security reasons" explanation for why both
java and python were forcing -L. -lplplot[d] on the gcc line above was a
reasonable explanation.  Which begs the question should we be doing extra
coding ourselves simply to avoid putting -L. -lplplot[d] on the gcc line? By
reading through the posts in historical order, you may have gotten the
impression this was still unsolved, but the configuration has long been
changed so that -L. -lplplot[d] or -L. -lplplottcltk[d] is done
appropriately for all drivers.

Alan