libltdl proposal for libgcj

[Anthony Green]

On Tue, 2004-07-13 at 00:49, Alexandre Oliva wrote:
> Yuck.
> 
> What's wrong with LD_LIBRARY_PATH, or using libtool to link with
> libtool libs?  Both should do the right thing.

No, not really.  Imagine I have FC2 installed, which includes
/usr/lib/lib-org-apache-xerces.so.

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!

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.