> On Feb 10, 2015, at 5:48 AM, Gabriel Moreno-Hagelsieb <gmh.entr...@gmail.com> > wrote: > > > Hello, > > When I try and install octave from source I get the following message: > Can't resolve dependency "system-java16-dev" for package "octave-3.8.2-6" (no > matching packages/versions found) > Exiting with failure. > > Which of course, means that I have no java 1.6 But I have java 1.8. I'd > rather not put an old java there. Would the package work with java 1.8? Would > you change the requirement to >= 1.6, rather than == 1.6? > > Best, > -GMH > > Gabriel Moreno-Hagelsieb > Department of Biology > Wilfrid Laurier University > 75 University Ave W > Waterloo, ON > Canada N2L 3C5 > (519)884-0710 ext 2364 > > --Unix is user friendly, just rather selective about its friends
Short answer: The different Java versions coexist, and if you install the legacy Java-1.6 from http://support.apple.com/downloads/DL1572/en_US/JavaForOSX2014-001.dmg that shouldn’t disrupt your existing setup. There’s absolutely no possibility to put a >=1.6 because on OS X Java 1.6 and later versions are completely different internally. The upstream build assumes Java-1.6, but adjusting it to use Java-1.7 or later _might_ be possible. Long answer: Here are the issues currently: 1) The default Octave build assumes that it will use the Java-1.6 framework. This can be patched out easily enough. 2) Octave _links_ to the JVM library, which is not best practice, according to what I’ve been told. For Java-1.6 we have: $ otool -L /sw/lib/octave/3.8.2/liboctinterp.2.dylib /sw/lib/octave/3.8.2/liboctinterp.2.dylib: /sw/lib/octave/3.8.2/liboctinterp.2.dylib (compatibility version 3.0.0, current version 3.0.0) /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version 1.0.0, current version 1.0.0) … On the other hand, for Java-1.7 and 10.8, the corresponding library is (for example): otool -D /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/server/libjvm.dylib /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre/lib/server/libjvm.dylib: @rpath/libjvm.dylib So Java-1.6 and later versions are incompatible from the point of view of linking. 3) Unfortunately, by policy we really can’t tweak the Octave build to resolve the runtime path (@rpath) directly, because the location varies by JDK version, and we don’t have a mechanism to enforce that. Everybody’s builds are supposed to be as identical on a given platform as we can make them. It might be possible to use a wrapper script for octave, though, to do something like what the original poster in http://stackoverflow.com/questions/14656657/linking-a-dynamic-library-libjvm-dylib-in-mac-os-x-rpath-issue did. That way the full path to whatever libjvm.dylib is present at compile time isn’t encoded anywhere. 4) I haven’t really had the time to explore this. -- Alexander Hansen, Ph.D. Fink User Liaison ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
