[Plplot-devel] RE: [Plplot-cvs] CVS update notice (plplot/cf)

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

Alan W. Irwin writes:
 > Update of /cvsroot/plplot/plplot/cf
 > In directory usw-pr-cvs1:/tmp/cvs-serv14482
 > 
 > Modified Files:
 > 	configure.in dyndrv.in 
 > Log Message:
 > New name for dynamic drivers:  drivers/*.drv ==> drivers/*_drv.so.
 > (For one key test case valgrind was getting confused by the lack of ".so"
 > on the ends of the driver dll's so I decided to put such a name-ending in
 > there in case there was a similar dynamic loader assumption that was
 > giving us the pecular results discussed below.)
 > 
 > Configuration support for linking libplplot against the tk, xwin, and tkwin
 > dynamic drivers.
 > 
 > In dyndrv.in commented out the link of all drivers against libplplot and
 > also got rid of the corresponding Makefile dependencies.  This change was
 > necessary to remove a circular Makefile dependency (libplplot depends on tk,
 > xwin, and tkwin dynamic drivers while those drivers depend in turn on
 > libplplot.) 
 > 
 > This change gives no linker errors and fine results for directly loaded
 > examples such as x01c, but dynamically loaded examples from python (and
 > apparently from java also according to the warnings in the comments about
 > this) no longer work.  

Uhbabubabuh.  What's the story on this?  Has this been resolved?
There are a bunch of RTLD_* flags (see man dlopen) that come into play
here.  It's pretty important that dyndrivers keep working inside a
jvm, methinx.  Has this been resolved (I'm still catching up on plplot
email).

 > Also after this change valgrind started complaining about the name
 > of the dynamic driver (so I changed it as above).  

Mmm, I should've known that would eventually bite us.  I was just
tickled pink when I learned dlopen could open a file regardless of
name, and I thought .drv was better than .so, so people wouldn't think
the drivers were "libraries" :-).  <chuckle>.

 > None of the
 > results of this change make sense to me so more discussion will be
 > required on list to get this straightened out.

I haven't yet formulated an opinion of what I think about all this
"drivers as libraries" business.  My gut says the JNI "ENV" thing is
the right way to solve these issues, and leave drivers as drivers, and
libraries as libraries.  But I"m not caught up yet, so I won't declare
this to be my final opinion yet.

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