atom feed11 messages in net.java.openjdk.bsd-port-devRe: new problem: libjava.dylib: image...
FromSent OnAttachments
Stephen BannaschJan 18, 2010 4:02 pm 
Ugo KanainJan 18, 2010 6:38 pm 
David GreenJan 18, 2010 7:22 pm 
Stephen BannaschJan 19, 2010 7:37 am 
John RoseJan 25, 2010 6:51 pm 
John RoseJan 26, 2010 6:15 pm 
Mike SwinglerJan 26, 2010 6:40 pm 
John RoseJan 26, 2010 8:51 pm 
John RoseJan 26, 2010 11:08 pm 
Greg LewisJan 27, 2010 2:02 pm 
John RoseJan 27, 2010 2:23 pm 
Subject:Re: new problem: libjava.dylib: image not found -- but it is there
From:John Rose (John@Sun.COM)
Date:Jan 26, 2010 6:15:59 pm
List:net.java.openjdk.bsd-port-dev

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

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.

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.