libltdl proposal for libgcj

Tue Jul 13 19:39:00 GMT 2004

Bryce McKinlay writes:
 > 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.
Yes, I'm sure this is a good idea. All my work on the branch is done
with this name-based resolution scheme turned off. I don't think it's
very helpful for many big applications.
Andrew.