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

Wed Nov 22 16:02:00 GMT 2006

Andrew Haley wrote:
> 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.
>>You could use System.load("/full/path/to/library.so") instead of 
System.loadLibrary("libraryName").
I know that on Sun's JRE that this will force it to load the exact file 
specified. One would assume that libgcj does the same.
David Daney.