Re: [Plplot-devel] New problems

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

On Thursday 11 October 2001 21:34, Geoffrey Furnish wrote:
| Geoffrey Furnish writes:
|  > I'm having some problems with the source after a recent update.
|  >
|  > 1) The dynamic drivers don't work inside Java anymore.  I traced
|  > this down to a recent change in drivers.in which removed
|  > libplplot from the driver linking step.  The reason this was
|  > there was explained in dyndrv.in, commit for version 1.3.=20
|  > Basically the issue is that there are multiple ways dlopen can
|  > be used (this panoply of RTLD_* flags), and the way we do it in
|  > libplplot when opening the drivers is more lenient than how the
|  > JVM does it when loading libplplot.  So, the drivers need to be
|  > linked against libplplot.  Maybe they don't have to be linked
|  > against all the other libs, if libplplot is now free of them,
|  > but the drivers still make some calls into the core of
|  > libplplot, so they have to be linked against at least that.=20
|  > I'll take care of this (again).

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:

> gcc x01c.c -o x01c -L/usr/local/test/lib -I/usr/local/test/include=20
-lplplot -Wl,-rpath -Wl,/usr/local/test/lib

then,

> ./x01c -dev ntk=20
Plplot library version: 5.0.4

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

and it work. Also for tk (that is static, not dyndrv).

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:

> 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)


| 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

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.

The plrender problem, is also not completely reprodutible for me:

> ./x01c -dev plmeta -o po.plm
Plplot library version: 5.0.4

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

> /usr/local/test/bin/plrender po.plm -dev xwin

Cannot open library file: drivers/drivers.db
lib dir=3D"/usr/local/test/lib/plplot5.0.4/data"

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.

There is really a problem with the tk driver, as you said:

> /usr/local/test/bin/plrender po.plm -dev tk

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

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.

Thus, the tk problem is another problem. Or maybe not?

Joao

|
| That's just one example, but there is some set of external PLplot
| API symbols showing up in every one I've checked.  So libplplot.so
| really can't be remvoed from the list of dependencies for drivers.
|
| BTW, it would be /possible/ to break this dependency, if we
| introduced one of these cute structure dereferencing tricks like
| they do in the Java Native Interface (and I think someone was
| saying the TEA stubs thing is similar, though I haven't
| investigated that myself yet).
|
| Anyway, my point is just that there does exist a known technique
| for defeating this linker-visible symbol coupling, if it is
| sufficiently disturbing to justify the effort.  Right now, I'm not
| sufficiently disturbed by the coupling to do this work, I'm just
| gonna augment the driver production rules so they are fully linked.
|  But if in the future anyone /really really really/ wants this
| broken, then we should do it the right way, with one of these
| structure pointer tricks.