RE: libgcj-4 puts /usr/lib before LD_LIBRARY_PATH in any case

[Andrew Haley <aph at redhat dot com>]

Yuval Kfir writes:
 > Andrew Haley writes:
 > > Yuval Kfir writes:
 > >  > Your system configuration is slightly different, Andrew, but
 > >  > you _have_ in fact reproduced the problem: before searching
 > >  > /mnt/zebedee and /home/aph/..., the Java run-time looks for
 > >  > libpoo under /usr/lib64/gcj-4.1.1.
 > > 
 > > Yes.
 > > 
 > >  > If there were a gcj-related library named libpoo, it would
 > >  > have found it before your library, no matter how you set up
 > >  > LD_LIBRARY_PATH.
 > > 
 > > Then the system is not installed correctly.  Why would anyone put such
 > > a lib in the gcj version-specific library /usr/lib64/gcj-4.1.1?
 > > 
 > >  > Where does the 'pre-configured' /usr/lib64/gcj-4.1.1, in your case,
 > >  > come from?
 > > 
 > > It's part of gcj.
 > 
 > Thank you for this analysis.  So, the problem I'm having here seems to
 > stem from two unfortunate factors:
 > 
 > 1. In our case, the pre-configured library path for gcj (on Fedora Core
 > 4) seems to be /usr/lib.

OK.  It might be that this is something we've fixed since then.  I
can't remember the history.

 > 2. One of our libraries is named libuuid.so, duplicating the name of an
 > existing /usr/lib library.
 > 
 > Hence, gcj seems doomed to find the /usr/lib/libuuid.so before it finds
 > our library.  Isn't there anything I can do, short of renaming one of
 > the two libraries?

Hmm.  It seems you have three options: rename the library, install a
more recent version of gcj, or debug the problem.  There's little
chance of persuading anyone else to revisit gcj 4.0.

Andrew.