Re: [Plplot-devel] New problems

[Geoffrey F. <fu...@ga...>]

Jo=E3o Cardoso writes:
 > OK, if you can't, you can't. But I can. I configure/installed in=20
 > /usr/local/test, then, as another user, compiled x01x.c:
 >=20
 > > gcc x01c.c -o x01c -L/usr/local/test/lib -I/usr/local/test/include=
=20
 > -lplplot -Wl,-rpath -Wl,/usr/local/test/lib
 >=20
 > then,
 >=20
 > > ./x01c -dev ntk=20
 > Plplot library version: 5.0.4
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > Device not loaded!
 > tag=3Dntk, drvidx=3D12
 > Trying to load ntk.drv on ./drivers/ntk.drv
 > Trying to load at /usr/local/test/lib/drivers/ntk.drv
 >=20
 > and it work. Also for tk (that is static, not dyndrv).

Right, that's because the way /we/ do dlopen in libplplot, allows the
resolution of symbols in the loaded module, against the symbols in
libplplot.  So, for an app linked to libplplot, the use of a dynamic
driver is easy.

But that's not the only usage model...

 > My understanding of dlopen() is that the libraries that the opening=20=

 > program was linked with are available to the dlopened code, so there=
=20
 > is no need to link it again with the same libraries. This works for=20=

 > other programs also:
 >=20
 > > ldd /usr/X11R6/lib/modules/xie.so=20
 >         libm.so.6 =3D> /lib/libm.so.6 (0x4008b000)
 >         libc.so.6 =3D> /lib/libc.so.6 (0x400a8000)
 >         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)

Your statement is true some of the time.  It depends on the flags used
in all the dlopen calls.  The way /we/ do it, makes the above
statement true.  The way the JVM does it, as one notable
counterexample, does not allow this.

 > | BTW, just in case there is any skepticism about this, here is how
 > | you can see for sure that every driver depends on libplplot:
 > |
 > | plplot/tmp> nm drivers/pbm.drv | grep " U "
 > |          U ___brk_addr@@GLIBC_2.0
 > |          U __curbrk@@GLIBC_2.0
 > |          U __environ@@GLIBC_2.0
 > |          U atexit@@GLIBC_2.0
 > |          U fclose@@GLIBC_2.1
 > |          U fprintf@@GLIBC_2.0
 > |          U fwrite@@GLIBC_2.0
 > |          U pdf_finit
 > |          U plFamInit
 > |          U plOpenFile
 > |          U plP_setphy
 > |          U plP_setpxl
 >=20
 > Those are resolved at *load* time, and as the "calling" program has=20=

 > "loaded" the libraries (libplplot, etc), everything is OK.
 > This is how I understand it, and it works for me.

Correct.  This is the way /we/ do it.  When /we/ load the driver into
libplplot.so, we allow it to do the run-time symbol resolution agsint
symbols already in our address space.

But not all users of dlopen are so permissive.  In my opinion, we need
to do one of two things:

1) bind the symbols so that non-permisive dlopen contexts will still
support use of PLplot with dynamic drivers, or

2) break the symbol resolution requirement.

Last night I was thinking more about this, after my mail yesterday,
and I am starting to feel some resolve for just doing 2) now.  I have
done the 1) thing in my makefiles (cf stuff), and am prepared to
commit that now, just to relieve the immediate pressure.  But I forsee
this thorn sticking us in the rump a few more times before we die of
old age, so I am starting to think that introducing a structure
dereferencing thing to break this symbol resolution requirement, may
be the best alternative, even if I didn't really want to be driven
into this so early in the game.

Thinking, thinking, thinking...

 > The plrender problem, is also not completely reprodutible for me:
 >=20
 > > ./x01c -dev plmeta -o po.plm
 > Plplot library version: 5.0.4
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > Device not loaded!
 > tag=3Dplm, drvidx=3D0
 > Trying to load plmeta.drv on ./drivers/plmeta.drv
 > Trying to load at /usr/local/test/lib/drivers/plmeta.drv
 > Opened po.plm
 >=20
 > > /usr/local/test/bin/plrender po.plm -dev xwin
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 >=20
 > That's OK. Also for ntk and gnome, but there seems to be a problem,=20=

 > they quickly render the page and quit after that.

Umm, haven't noticed this.  Hmm.  I just ran x07c, directed to a
plmeta file, then ran my installed $prefix/bin/plrender on the
resulting multi-page plmeta file, and it renders fine with xwin,
pausing between each page as usual, etc.  But when I try to render
with the tk driver, it fails, even though if I run x-7c -dev tk, it
works fine.  So there is some problem with the Tk driver when it is
installed, or with plrender, or something.  Not sure which.

 > There is really a problem with the tk driver, as you said:
 >=20
 > > /usr/local/test/bin/plrender po.plm -dev tk
 >=20
 > Cannot open library file: drivers/drivers.db
 > lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"
 > TCL command "/usr/local/plplot/lib/drivers/drivers.db" failed:
 >          invalid command name=20
 > "/usr/local/plplot/lib/drivers/drivers.db"
 > Program aborted
 >=20
 > But, given that the others run OK, I am inclined to another problem.=

 > tk is static, dont work,
 > xwin is static, works,
 > ntk, gnome are dynamic, work.
 > ps, psc, etc are dynamic also work OK.
 >=20
 > Thus, the tk problem is another problem. Or maybe not?

Yes, I believe the problem with the Tk driver is likely unrelated to
the issue with the semantics of linking the dynamic drivers.  BTW,
I've fixed the driver linking thing in my local copy, but the Tk
driver from plrender, is still nonfunctional.  So I believe this is a
separate problem, which I think I have not induced through my own
blunders in my own working copy.

--=20
Geoffrey Furnish         fu...@ga...