"jean-frederic clere" <[EMAIL PROTECTED]> wrote:

>> The JVM _is_ behaving correctly, no bug whatsoever, the problem is that you
>> don't have to confuse a pluging (MH_BUNDLE, RTLD_LOCAL) with a library
>> (DYLIB, RTLD_GLOBAL)... All nice and clean.
> 
> Is testing on moof.apache.org a good idea?

No need to do that, just straight out and make your assumptions correctly...

> man dlopen there shows the following:
> +++
> BUGS
>     An error that occurs while processing a dlopen() request results in the
>     termination of the program.
> +++

That's weird as "dlopen()" is not even defined on MacOS/X :-( You shouldn't
see that man page...

And the problem is NOT on OS/X itself, it would repeat itself on any
platform:

How does dynamic linking occur? A DSO (dynamic shared object) is a piece of
code (usually a library) which gets loaded by the kernel in a shared memory
space for the benefit of all applications.

Once linking is done, a "hint table" containing all associations
symbol_name->pointer_to_function is set in the process to access the
functions provided by the library. For each process there is ONE global hint
table and several local tables: the global table contains all pointers to
functions of the libraries linked in by the process loader, and the local
tables contain all functions of the libraries loaded by the application
itself.

There is a way to "force" the allocation of all symbols to happen in the
global table, but this must be used with care, as what happens is that if
there's a duplicate symbol definition, well, things might get _really_
weird. So, what happens if you load a library with the JVM? The JVM loads
the library and allocates a LOCAL symbols table. The problem is that if this
library is linked to another library, the allocation of symbols of this
second library should happen in the GLOBAL table, (case of JF loading APR
which is linked to crypt)... Since you are loading APR local, you can't
allocate stuff in global, and because of that, you get a nice linkage error.

The _ONLY_ solution is to either force a GLOBAL loading of (let's say) APR
by a third library which is loaded LOCALLY and loads APR globally (a let's
say JNI->APR liaison) but at  that point the linkage may fail, and you have
to handle all the cases when this happens, or to preload the library at
startup, either by linking your executable binary with the required library,
or using the LD_PRELOAD environment variable. If things get messy at that
point, the kernel will simply avoid to even start the process, and exit.

    Pier

--
I think that it's extremely foolish to name a server after the current U.S.
President.                                                 B.W. Fitzpatrick



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to