libltdl proposal for libgcj

[Alexandre Oliva]

On Jul 13, 2004, Anthony Green <green@redhat.com> wrote:

>  Class.forName ("org.apache.xerces.parsers.DOMParser")
> ... the new libgcj is going to start looking for this class in a .so,
> starting with lib-org-apache-xerces-parsers-DOMParser.so, and eventually
> working it's way down to lib-org-apache-xerces.so.  Along the way, it
> looks in LD_LIBRARY_PATH, /lib and /usr/lib.  But we don't want it to
> find the lib-org-apache-xerces.so in /usr/lib, since the ABI is
> different.

- Have a symbol that tells what ABI the library complies with, and
immediately dlclose libraries that fail to define the right ABI
symbol, proceeding to the .class loading mechanism, and/or

- make sure loading two different, incompatible versions of libgcj.so
(that presumably this lib-org-apache-xerces.so would attempt to bring
in) fail, and/or

- use libltdl's (recent) module loader interface to get libltdl to
search for .jar/.class files in the same directories as it would
search for .so files (or something to that effect), which might
hopefully avoid the ABI incompatibility issue.  Better check that it
will actually iterate on (search dirs, module loader) instead of just
calling the various module loader open functions and leaving dir
searching up to them, and/or

- change the naming convention of shared libraries for the newer
ABI

> My initial idea was for libltdl to unlearn about /lib:/usr/lib.  The
> problem is that libltdl eventually falls back to calling dlopen with
> "lib-org-apache-xerces.so", and dlopen will find the one in /usr/lib for
> us.

I think you're fixing the wrong problem.  You don't want to remove
these directories.  You want to avoid loading ABI-incompatible
libraries.  I suggest that you focus on the actual problem, instead of
adding a kludge to the dynamic loader machinery.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}