> Hmm...here's what I get from the default OS X build:
>
> $ otool -L /sw/lib/octave/3.8.1/liboctinterp.2.dylib
> /sw/lib/octave/3.8.1/liboctinterp.2.dylib:
> /sw/lib/octave/3.8.1/liboctinterp.2.dylib (compatibility version
> 3.0.0, current version 3.0.0)
> /System/Library/Frameworks/Java
On 5/21/14, 4:36 PM, Benjamin Reed wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 5/21/14, 6:30 PM, Alexander Hansen wrote:
>> Maybe upstream oughtn't be linking it then?
>
> I suppose if you're actually embedding the JVM *into* your program,
> maybe? That's the only reason I can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/21/14, 6:30 PM, Alexander Hansen wrote:
> Maybe upstream oughtn't be linking it then?
I suppose if you're actually embedding the JVM *into* your program,
maybe? That's the only reason I can think of that linking libjvm
would actually be legitima
On 5/21/14, 2:34 PM, Benjamin Reed wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Oop, did more digging, and I was wrong. There *are* some header
> things that change, so the rules for linking a jnilib should be the
> same for jars; if you build it on any 1.6 JDK, it should load on a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oop, did more digging, and I was wrong. There *are* some header
things that change, so the rules for linking a jnilib should be the
same for jars; if you build it on any 1.6 JDK, it should load on any
later JDK, and so on. You can't build a jnilib wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/21/14, 4:51 PM, Alexander Hansen wrote:
> Anybody happen to know what the best way to handle builds against
> Oracle's JDKs? They don't use a framework, there's not an
> unversioned link anywhere so using hardcoded paths is fragile, and
> the pr
Anybody happen to know what the best way to handle builds against
Oracle's JDKs? They don't use a framework, there's not an unversioned
link anywhere so using hardcoded paths is fragile, and the preferred
method of @rpath is problematic because of those hardcoded paths--in
particular I'm think
