[Plplot-devel] Problem solved! (was png driver no longer works for python)

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

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 b=
e
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 dynamicall=
y
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=
=2E

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.  I have subsequently fixed those 3 missing
$(driverlibs) problems, and committed to cvs.

I now find

=2E/pythondemos.py -dev png -fam -fflen 2 -o test.png

works great as does

=2E/pythondemos.py -dev ntk.

=2E/pythondemos.py -dev gnome crashes immediately, but as I recall Rafael w=
as
never satisfied with the gnome driver so I am not going to worry about that
until he brings it into more final state.  (But please take note, Rafael,
of this problem for future reference.)

I believe these fixes work for the png and ntk cases because $(driverlibs)
includes a reference to libplplot which is supplying the missing symbol.  I
have no idea how this missing symbol was supplied before for (say) x01c or
other C examples that worked in the past with the dynamic gd driver.  I
guess with this odd mixture of dynamic loading and ordinary run-time loadin=
g
that occurs for python, library order matters for resolving symbols more
than for the C front-end case where libplplot is run-time loaded right away=
=2E

BTW, Joao.  This was my first chance to try out your ntk driver. I am reall=
y
glad you made that effort.  It gives some nice-looking results for the 46
pages generated by pythondemos.py in an amazingly short amount of time.

Alan