new problem: libjava.dylib: image not found -- but it is there

[Mike Swingler]

The BSD Makefile should definitely specify some link directives.

On Mac OS X, dyld uses a stack of "rpath" directives that are pushed by each library that is loaded (the dyld man page has more info in the "DYNAMIC LIBRARY LOADING" section). We have recently started building the Apple JDK with @rpath-based paths to avoid using a full path in each libraries "install_name", which is included by each library that links against it.

Each library needs to be built with with an @rpath-relative install_name:
-install_name @rpath/$(LIB_PREFIX)$(LIBRARY).$(LIBRARY_SUFFIX)

As well as the "push rpath" directives, for example:
-Xlinker -rpath -Xlinker @loader_path/../lib
-Xlinker -rpath -Xlinker @loader_path/../jre/lib

Also, the bin tools need to have "push rpath" directives as well, so you'll probably need to experiment with a number of different paths to find a combination that builds a coherent JDK.

Best of luck,
Mike Swingler
Java Runtime Engineer
Apple Inc.

On Jan 26, 2010, at 6:16 PM, John Rose wrote:

> One of the significant differences between the makefiles for linux and bsd is this:
> 
> -ifdef LIBRARY
> -  # Libraries need to locate other libraries at runtime, and you can tell
> -  #   a library where to look by way of the dynamic runpaths (RPATH or RUNPATH)
> -  #   buried inside the .so. The $ORIGIN says to look relative to where
> -  #   the library itself is and it can be followed with relative paths from
> -  #   that. By default we always look in $ORIGIN, optionally we add relative
> -  #   paths if the Makefile sets LD_RUNPATH_EXTRAS to those relative paths.
> -  #   On Linux we add a flag -z origin, not sure if this is necessary, but 
> -  #   doesn't seem to hurt.
> -  #   The environment variable LD_LIBRARY_PATH will over-ride these runpaths.
> -  #   Try: 'readelf -d lib*.so' to see these settings in a library.
> -  #
> -  LDFLAGS_COMMON += -Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$$ORIGIN
> -  LDFLAGS_COMMON += $(LD_RUNPATH_EXTRAS:%=-Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$$ORIGIN/%)
> -endif
> 
> (See output of "diff -u make/common/Defs-{linux,bsd}.gmk".)
> 
> I don't know if there is an equivalent BSD dyld feature for Solaris and Linux $ORIGIN, but the lack of it, or the lack of use of it, may be causing the problem we are seeing.
> 
> The $ORIGIN hack seems like the sort of thing which Mac OS X would do better; does anyone know the Mac or BSD story here?
> 
> The original version of the BSD file omits mention of LD_RUNPATH_EXTRAS, while the original version of linux and solaris files has it, so it's hard to tell who to ask about the change.
> 
> -- John
> 
> On Jan 25, 2010, at 6:51 PM, John Rose wrote:
> 
>> I asked around at the office, and here's a possible root of the problem:
>>  http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/de45eac5670e
>> 
>> The launcher (java.c in the jdk repo) used to re-exec itself with LD_LIBRARY_PATH bindings, so the libjvm and libjava DLLs could find each other.  This trick was always awkward, and has been removed.
>> 
>> Now the various DLLs have their pathnames baked into them at compile time, as *relative* paths.  Perhaps this logic needs extra porting, or maybe there is a difference in behavior w.r.t. relative DLL paths on Mac OS.  The error message (which comes from libjvm code) suggests that the launcher finds libjvm OK, and libjvm can find libjava OK, but when libjvm tries to open libjava, the reverse references from libjava to libjvm don't resolve properly, and the dlopen fails.
>> 
>> -- John
>> 
>> On Jan 19, 2010, at 7:38 AM, Stephen Bannasch wrote:
>> 
>>>> I built JDK7 today based on these instructions http://wikis.sun.com/display/OpenJDK/Darwin9Build
>>>> 
>>>> I'm experiencing the same problem.
>>> 
>>> One possible clue is that the libjava.dylib files itself doesn't appear to be the problem.
>>> 
>>> This is the latest build I have that doesn't work:
>>> 
>>>  [local]$ java-1.7.0-internal-2010_01_18/bin/java -version
>>>  Error occurred during initialization of VM
>>>  Unable to load native library: dlopen(/usr/local/java-1.7.0-internal-2010_01_18/jre/lib/i386/libjava.dylib, 1): Library not loaded: libjvm.dylib
>>>    Referenced from: /usr/local/java-1.7.0-internal-2010_01_18/jre/lib/i386/libjava.dylib
>>>    Reason: image not found
>>> 
>>> Here's a build from Dec 26 that does work:
>>> 
>>>  [local]$ java-1.7.0-internal-2009_12_26/bin/java -version
>>>  openjdk version "1.7.0-internal"
>>>  OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2009_12_26_16_00-b00)
>>>  OpenJDK Server VM (build 17.0-b05, mixed mode)
>>> 
>>> libjava.dylib is identical:
>>> 
>>>  [local]$ diff java-1.7.0-internal-2010_01_18/jre/lib/i386/libjava.dylib java-1.7.0-internal-2009_12_26/jre/lib/i386/libjava.dylib
>>> 
>>> However the bin/java files differ.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20100126/87dd5a2f/attachment.html