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

[David Daney <ddaney at avtrex dot com>]

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.