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

[Alan W. I. <ir...@be...>]

On Mon, 2 Sep 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Update of /cvsroot/plplot/plplot/cf
>  > In directory usw-pr-cvs1:/tmp/cvs-serv14482
>  >
>  > Modified Files:
>  > 	configure.in dyndrv.in
[...]
>  > 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).

Yes, it has been resolved.  My guess is this problem is the result of a bug
in the way java and python dlopen libplplot under Linux.  When the driver is
dlopened, libplplot has already been dlopened.  Thus, if the appropriate
RTLD flag were used on the *libplplot* dlopen by java or python, it shouldn't
really be necessary to link the drivers with libplplot. However, I expect
that flag is missing because when you do link the drivers with libplplot the
problem with python and java disappeared.

BTW, I am now comfortable with linking the drivers with libplplot (or
libplplottcltk as appropriate) because it is entirely consistent with the
linking pattern that works in all other cases. That is, if *explicit*
linking dependencies appear in any shared object (and of course every driver
depends on either libplplot or libplplottcltk), then the appropriate library
must be linked when the shared object is created.  But that explicit
dependency case is the *only* library linking that is necessary.  In
particular, so as not to obfuscate the required linking, I have removed all
the unneeded library linking that has been put in in the past so you will
see some greatly simplified linking lines under Linux now.


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

In future, I gotta be careful of such statements in commit messages...;-) It
makes much more sense to me now.

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

As far as the linker is concerned, they are all shared objects which can be
linked at run-time or dlopened (dynamically linked).  So from that point of
view there is absolutely no distinction between (dynamic) drivers and
libraries.  However, there is one important distinction that we have to keep
in mind for ourselves; we know in advance that all drivers depend on
libplplot or libplplottcltk so to avoid circular dependencies it is
important that nothing in those libraries depends explicitly on anything in
the drivers.  Maurice solved that problem for the xwin driver by using
an escape function approach.  In the tkwin case, it was solved by moving
objects from libplplottcltk to the tkwin shared object.

Alan