libltdl proposal for libgcj

Tue Jul 13 18:55:00 GMT 2004

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