This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: java/lang/

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > Michael Koch writes:
 > >  > > > +      char* libraryPath = ::getenv ("LD_LIBRARY_PATH");
 > >  > >
 > >  > > Sorry, but I don't think this is portable. For example,
 > >  > > on Windows, PATH is used to search for DLLs. My memory
 > >  > > is a bit hazy now, but on AIX it was something like
 > >  > 
 > >  > Well, getenv() is used in one other place in this file too. Thats why 
 > >  > I decided to use this. I can write a patch included the AIX variable 
 > >  > later today
 > > 
 > > If I recall correctly, Darwin uses something different again.  
 > It seems to use "DYLD_LIBRARY_PATH":
 > > Well, I have to ask what this is for.  Any gcj application that uses
 > > this will be fragile and have reduced portability.  The shared library
 > > loader searches its path using its own algorithms.  Why does a gcj
 > > program need to know this stuff as well?
 > For one, this is one of those mandatory System properties that a
 > JRE should be able to return (see JavaDoc for
 > System.getProperties()). Maybe it is used by Sun's implementation
 > of System.loadLibrary( ) and for some reason they thought it a
 > useful property to expose. (For example, if a Java application is
 > not able to load its JNI library, it can crib usefully asking the
 > user to put the library in one of the folders in this path...)

Sigh.  This one seems quite bizarre, but I guess we're stuck with it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]