DYLD_FALLBACK_LIBRARY_PATH changed in OpenJDK (was Re: How to load dylib on Mac?)

[Weijun Wang]

Oh, I didn't notice the case insensitive name matching part.

But with the current implementation, libs in /usr/lib cannot be
dlopen()'ed. For example, the following paragraphs shows that the native
JGSS provider cannot be loaded:

$ cat A.java
class A {
  public static void main(String[] args) throws Exception {
    System.out.println(System.getProperty("os.name"));
    new sun.security.jgss.wrapper.SunNativeProvider();
  }
}

$ java -Dsun.security.nativegss.debug=true
-Dsun.security.jgss.lib=libgssapi_krb5.dylib A

Darwin
SunNativeGSS: [GSSLibStub_init] libName=libgssapi_krb5.dylib
SunNativeGSS: dlopen(libgssapi_krb5.dylib, 2): image not found

$ DYLD_LIBRARY_PATH=/usr/lib java -Dsun.security.nativegss.debug=true
-Dsun.security.jgss.lib=libgssapi_krb5.dylib A

Darwin
SunNativeGSS: [GSSLibStub_init] libName=libgssapi_krb5.dylib
SunNativeGSS: Loaded GSS library: libgssapi_krb5.dylib
SunNativeGSS: Native MF for 1.2.840.113554.1.2.2
SunNativeGSS: Native MF for 1.3.5.1.5.2
SunNativeGSS: Native MF for 1.2.840.48018.1.2.2
SunNativeGSS: Native MF for 1.3.6.1.5.5.2

Thanks
Max


Landon Fuller wrote:
> 
> On Jul 24, 2009, at 8:11 AM, Max (Weijun) Wang wrote:
> 
>> In fact, why is DYLD_FALLBACK_LIBRARY_PATH updated in src/solaris/bin/
>> java_md.c? Why not DYLD_LIBRARY_PATH?
>>
>> DYLD_LIBRARY_PATH should be preferred than DYLD_FALLBACK_LIBRARY_PATH.
>> If the libjpeg.dylib is in DYLD_LIBRARY_PATH, it will be loaded
>> instead of /usr/lib/libjpeg.dylib.
> 
> If DYLD_LIBRARY_PATH is set, it can cause library name conflicts. By
> default, Mach-O records the path to libraries, rather than only their
> name. Setting DYLD_LIBRARY_PATH results in this path being overridden,
> and case insensitive name matching occurs first, instead.
> 
> One example of this is the JDK's libjpeg.dylib, which conflicts with
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
> 
> 
> This should probably be revisited, as it may be possible to remove the
> use of DYLD_* variables via the use of executable/library-relative
> @rpath, @executable_path, and/or @loader_path install_name values.
> 
> -landonf
> 
> 
> ------------------------------------------------------------------------
> 
>