[Plplot-devel] Problem solved! (Was: Help needed for dynamic linking problem on linux)

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

On Sun, 14 Jul 2002, Alan W. Irwin wrote:

> ==17017== discard syms in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/drivers/psd_drv.so due to munmap()
> ==17017== discard 0 (0 -> 0) translations in range 0x43ADB000 .. 0x43AE1FFF
> Unable to load driver: psd_drv.so.
> Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: cannot open shared object file: No such file or directory


Update: The discard sysm and discard 0 messages are legit, but the reason is
wrong.  What's going on here is ./drivers/psd_drv.so fails in plplot/tmp so
the plcore code tries a second time in the install location which I had
cleaned out so that fails as well with that resulting error message.  If I
simply copy ./drivers/psd_drv.so to the install location, I get the correct
error message:

Unable to load driver: psd_drv.so.
Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: undefined symbol: plRotPhy

What's going on is that psd_drv.so has some undefined symbols (presumably
plRotPhy is the first of these to be encountered) from libplplot that cannot
be resolved by the dynamic loader despite the fact that libplplot has
already been dynamically loaded.  My best guess for the cause of this is
that python (and java) use dlopen to load libplplot in the first place, and
they do not use the RTLD_GLOBAL flag which can be ORed with the RTLD_NOW or
RTLD_LAZY options for dlopen.  The point of RTLD_GLOBAL is "the external
symbols defined in the library will be made available to subsequently loaded
libraries" according to the excellent documentation I found at
http://www.tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html.
Presumably, the dynamic loader invoked when libplplot is simply used as a
shared library (i.e., when x??c is invoked) effectively sets this flag so
that libplplot symbols such as plRotPhy can be resolved in psd_drv.so.

So my tentative conclusion is that the dlopen calls in the python extension
interface (and the java equivalent) forgot to OR in RTLD_GLOBAL with their
dlopen flag (since dlopening a library which in turn dlopens another library
depending on the symbols of the first library is a scenario they probably
didn't think about).

Bottom line: gotta work around this problem myself.  The solution which I
have just committed is to have libplplot link to the "special" drivers tk,
xwin, and tkwin and all other "ordinary" drivers link the other way to
plplot.  My spot checks indicated everything works with this solution.

Status: there are still some things to clean up.  For example, I just
committed a bugfix for plplot.h which solves one bug and also now allows (at
least from my preliminary tests) tk to be moved from the special to the
ordinary list.  Also, the install has to be fixed up to deal with the
special dynamic drivers.  But fundamentally, I think I have the dynamic
driver linking problems whipped.

Alan