Re: [Plplot-devel] New problems

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

On Friday 12 October 2001 17:08, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
=2E..

|  > The dlopen() man page says:
|  >
|  >        External  references in the library [jc: the dlopened program=
]
|  >        are resolved using the libraries in that library's dependency
|  >        list [jc: I (we?) don't want that] and any  other
|  >        libraries previously opened with the RTLD_GLOBAL flag
|  >
|  > [jc: so I guess that in linux the loader opens the libraries the
|  > executable was linked against, with RTLD_GLOBAL, and
|  > as such their symbols are available to the dlopened program].
|  >
|  >        If the executable was linked with the flag "-rdynamic",  then
|  >        the  global symbols in the executable will also be used to
|  >        resolve references in a dynamically loaded library.
|
| Right.  I believe you understand correctly, everything that relates to
| understanding how our C programs, like the PLplot C demos, our own
| programs, etc, all work when linked against libplplot, and then using
| PLplot's dynamic drivers.
|
| Here's what you haven't yet grasped.
|
| When running a /Java/ program, the PLplot binding is accomplished by
| asking the JVM to "load" libplplot.  Evidently it does this by dlopen,
| but not using RTLD_GLOBAL.  Then, when libplplot dlopen's
| driver/xyz.drv, the driver doesn't have access to libplpot's symbols
| because libplplot itself wasn't loaded with RTLD_GLOBAL.
|
| I'm not defending the JVM behavior, I'm just reporting it.
|
| To live with it, we need to either
|
| 1) link drivers against libplplot, or
| 2) break the symbol resolution requirement.
|
| I'll /probably/ check in 1) soon.

Hi, it looks like you have not yet commited that change. Have you found a=
=20
work-around for this issue?

Joao

|  I will /possibly/ do 2) sooner than
| sometime in the indefinite future.  How's that for a vague statement
| of my intentions?  :-).