libltdl proposal for libgcj

Tue Jul 13 14:10:00 GMT 2004

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.