Re: How the "library naming scheme" works loading dynamical libraries?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Martin" == Martin Egholm Nielsen <martin@egholm-nielsen.dk> writes:

Martin> http://gcc.gnu.org/ml/java/2002-11/msg00394.html

There are some docs here:

http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcj/Extensions.html#Extensions

Seeing them in print like that makes me realize how much they could
stand to be fleshed out :-(

Martin> Fine! However, I'm not quite familiar with the mechanism that tracks
Martin> down the implementation, "bte", located in the library "lib-bte.so".

Martin> Does the class loader search each and every library in LD_LIBRARY_PATH
Martin> for this implementation? In it does, when does it do - at gcj
Martin> init-time or at Class.forName() invocation-time?

Whenever we search for a class we will look for a shared library
whose name is derived from the class.  Actually we search for a
series of libraries, stripping off components from the end.  So for
'base.pkg.Class' we will look for 'lib-base-pkg-Class',
'lib-base-pkg', and 'lib-base'.

We use libltdl to do the loading but ultimately this boils down to
dlopen().

There is a system property to set to change this behavior a little.
In particular you can turn it off or you can have it cache negative
results.  FWIW I think we'd like to switch the default to off as this
feature doesn't play too well with typical java applications.
(There's a PR for this.)

We do the search whenever a class is looked for, eg Class.forName(),
but also when linking a BC or interpreted class.

Martin> In case the library to "search" is determined by the argument to
Martin> Class.forName(), how does one create and use a shared library with
Martin> more than just one "implementation"?

This is one of the drawbacks of this approach.  In situations like
this, when you want to load classes with the same name into different
class loaders, you will most likely want to go with the BC ABI and the
class database instead.  See:

http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

Note that in the implementation we still may have to play ugly
tricks -- if we load a given .so more than once we will make a copy
of it.  We'd like to replace this with dlmopen() but nobody has
really investigated this in depth yet; there's a PR for it.

Tom