RE: [Plplot-devel] New problems

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

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.  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.  I'll take
 > care of this (again).

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

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.

-- 
Geoffrey Furnish         fu...@ga...