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.
>>
>>
>
>
