Geoffrey Furnish writes:
> Update of /cvsroot/plplot/plplot/bindings/java
> In directory usw-pr-cvs1:/tmp/cvs-serv5347/bindings/java
> Modified Files:
> Log Message:
Woops, sorry guys, this file got the wrong commit message due to a
cosmic biff in my editor. What actually happened with this file, is
that I implemented native method decls for a bunch more API entry
points, needed to implement x01.java.
12 down, 112 still to go.
> Fix very tricky error in building of the dynloadable drivers.
> C programs like x01c were working fine with dynamic drivers, but only
> accidentally. Specifically, references by the drivers to functions
> provided by libplplot, were being resolved in some cases as a result
> of the peculiarities of how the final executable was being built.
> However, in the case of the java binding, we don't control the way in
> which Java's System.loadLibrary( "plplot" ); manages the interraction
> with dlopen(), so we have to prime the pump. To make it all work, we
> have to actually link the drivers against libplplot.so, so that when
> the drivers are dynloaded into libplplot during the Java static init
> section in PLStream.java, they will actually resolve symbols against
> the (already loaded) libplplot.so.
> It all comes down to understanding dlopen() and friends. Evidently
> when the JVM does the external (native) load, it won't use
> RTLD_GLOBAL. I guess that makes some kind of sense from a security
> standpoint, although it complicates the situation for dynloadable
> libraries which want to dynload additional components.
> Anyway, it works now. The dynamic drivers can be loaded into
> executable programs compiled in the usual way (shown by the PLplot
> makefile), or into libplplot.so when libplplot.so is itself dynloaded
> into some other process, such as occurs in the case of the JVM loading
> the PLplot JNI binding dynamically.
> Plplot-cvs mailing list