Re: libltdl proposal for libgcj

[Bryce McKinlay <mckinlay at redhat dot com>]

Anthony Green wrote:

> Now imagine that I'm building a brand new ABI-incompatible gcj, and
> installing it in /usr/local.  I'd set LD_LIBRARY_PATH to point to
> /usr/local/lib.  Also imagine that I don't have a
> lib-org-apache-xerces.so in /usr/local/lib.  I'm counting on libgcj to
> fall back to reading bytecode on my CLASSPATH.  If I ran a program with
> this gij that does ...
> 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.
>
> 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.
>
> So, my "solution" for now is for libltdl to both unlearn about
> /lib:/usr/lib _and_ only call dlopen with absolute filenames.
>
> If you have a better idea, I'd love to hear it!
>  

I wonder if, with the new ABI, we ought to think about just ripping out 
this name-based resolution scheme. I'm thinking that some kind of 
extdir+classpath approach, with shared libraries instead of .jars, would 
solve the problem in a simpler and more Java-compatible way.

Class.forName() is potentially very slow because of all the dlopen() 
calls that it generates. That could probably be fixed by caching the 
results of past lookups, etc, but I do wonder if this whole lookup 
scheme is worth the effort.

Regards

Bryce