[Plplot-devel] dyn-drivers linking -- again!

[<jca...@in...>]

On Monday 26 November 2001 09:36, Alan W. Irwin wrote:
| I solved the problem.... Explanation below.
|
| On Mon, 26 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
| > As far as I know, all dynamic drivers are treated the same way,
| > as the procedure to load them is the same.
| > Thus, the problem is with python dynamic loading, not the gd
| > driver (that works for other bindings/programs). It must be one
| > of those environment variables that we like so much... I make no
| > idea.
| >
| > The problem is with python needing to load both libplplotd.so and
| > drivers/gd.drv. It founds the last, but not the first.
|
| I think the actual linking model is more complicated than that
| (which may be the source of the trouble).  I am no expert on
| linking so you may have to correct my mental model, but here is
| what I think is happening with the linking.  When plmodule.so is
| created, it is linked (not dynamically linked) to libplplot.  So at
| run time when you import pl, plmodule.so is dynamically linked by
| python.  When you execute say plinit from python, plmodule.so
| translates it to the appropriate libplplot call which is found and
| run-time linked by the ordinary loader (just the way you get access
| to any other library such as libc from plmodule.so).  libplplot
| itself then may make a dynamic load of the device drivers.  This
| whole complicated mechanism works fine for the psc device, but
| somehow it is falling apart for the png device.
|
| I therefore carefully went over the Makefile and found that
| $(driverlibs) was missing from the drivers/gd.drv build line as
| well as the equivalent ntk.drv and gnome.drv lines.

That was my fault, yes.
I always think in terms of compiled programs, not interpreted ones.=20
Compiled programs are linked against libplplot, and thus the drivers=20
"inherit" it. For the same to happen with python (java, etc), python=20
itself should be linked with libplplot, what is a nonsense.

But I still have one doubt. Currently, $driverlibs in dyndrv.in uses=20
all libs that libplplot is linked with; I think that the dyn-drivers=20
only needs to be linked with libplplot itself, (as libplplot itself=20
is linked with tclmatrix, etc, and as such the dyn-driver will find=20
them).

But this dyn-driver linking stuff has given so many problems (sorry=20
Geoffrey :) that I'm afraid to change it again. Anyhow, using=20

    driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)

only on dyndrv.in enables "./pythondemos.py -dev png -fam -o po.png"=20
to run OK. In Octave I also was able to use the png driver. I would=20
like to try the java bindings but somehow I forgot the environment=20
variables receipe (CLASSPATH=3Djava and LD_LIBRARY_PATH=3D`pwd` ? "make=20
jdemos" runs OK).=20

Can you check it out, Alan? I hate (OK, dislike, I'm a latin, you=20
know, I have strong feelings :) to do/have un-necessary things in the=20
code/Makefiles.

Joao