Re: java lib loading mechanism

[Alexander Hansen]

On Dec 22, 2014, at 9:45 AM, CdeMills <address@hidden> wrote:

Hello,

I've looked at the issues around the Java package (see bug #40111). The
problem boils down to loading libjvm.so, which is to be found in a
non-standard library path. Under Windows, "jvm.dll" is found from the
registry; the discussion applies to Unix and MacOs platforms.

Actual solution: determine at compile time its full path and call dlopen()
on a static string whose value is set to this path. The trouble is that this
stops working after an upgrade.

My proposal was to introduce an environment variable containing the full
path of the Java lib, which can be set in the .octaverc before calling any
function from the Java package.

The library path is setup as follows under Fedora21:
/usr/lib/java-openjdk-1.8.0-YYY/lib/server/
where YYY is a version number. In /usr/lib exist two more links to this dir:
/usr/lib/java-openjdk and /usr/lib/java-openjdk-1.8.
Another proposal is to use the relative name "libjvm.so", with,
1) at compile time: use "-ljvm" and
"-L/usr/lib/java-openjdk-1.8.0/lib/server" as switches
2) at run-time: set "LD_LIBRARY_PATH=/usr/lib/java-openjdk-1.8/lib/server"
before launching octave.
This solution would be less sensitive to system upgrade.

Would it be OK to introduce dynamic linking to the shared lib libjvm.so ?

Regards

Pascal




--
View this message in context: http://octave.1599824.n4.nabble.com/java-lib-loading-mechanism-tp4667911.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

My understanding from one of my project’s folks—whose day job is on a OpenNMS, a heavily Java-based project—is that _linking_ to libjvm isn’t best practice.  

Mac OS X is a giant pain in this regard.  There are two locations for Java on OS 10.6 and later:

1)  Java 1.6 as shipped by Apple up until 10.8 uses an OS X framework — Octave 3.8.x currently uses that (I haven’t looked into later development versions just yet, so feel free to correct me).  This can be installed on 10.9 and 10.8, but it’s not publicized.  The Octave 3.8.x build on OS Xis set up to link to this if Java is enabled.

2)  The current Java 1.7 and 1.8 from Oracle, by contrast, install in versioned directories (if you go for the development kit, rather than just the runtime-only browser plugin), but there aren’t any unversioned options.  For example, on my system I have:

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/server/libjvm.dylib

/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/lib/server/libjvm.dylib

/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib

Rather than providing an unversioned link, these rely on the use of  runtime paths via @rpath and the -rpath linker option:

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html

$ otool -L /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib

/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/libjvm.dylib:

@rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

http://stackoverflow.com/questions/14656657/linking-a-dynamic-library-libjvm-dylib-in-mac-os-x-rpath-issue suggests that providing a wrapper like Pascal suggested would work on OS X, too.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison