On Mac OS X there is a command, java_home, that returns the path for the user's enabled and preferred JVMs in the Java Preferences application. This command is Apple's advised way of defining the JAVA_HOME environment variable. On my system I get: $ /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home The user can add to its ~/.profile file (or equivalent) the line: export JAVA_HOME=`/usr/libexec/java_home` SWI-Prolog build script picks the value of the JAVA_HOME environment variable but there's a problem. The generated libjpl.dylib looks into the wrong place as you can check by typing: $ otool -L libjpl.dylib libjpl.dylib: /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version 1.0.0, current version 1.0.0). This can be corrected by typing: $ install_name_tool -change /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/server/libjvm.dylib libjpl.dylib Still, if you try a JPL call (e.g. Jpl:jpl_call/4), your SWI-Prolog process will end with an error that 'No Java runtime present, requesting install.' Oct 26, 2017 This package is exclusively intended for support of legacy software and installs the same deprecated version of Java 6 included in the 2015-001, 2014-001, and 2013-005 releases. Quit any Java applications before installing this update. And a system prompt to install Java 6! If you sigh, throw your hands in the air, surrender, and install Java 6 then JPL will happily work using Java 8. I suspect some lingering linking issue that the fix above is not enough to correct. Is possible that the problem is in the following line in the JPL Makefile: JAVALIBS=-Wl,-framework,JavaVM But I have no idea how to fix and still generate a.dylib. As it seems the jpl build is now broken on my machine and it merely includes the old version, this seems a good time to look into this. The first question is which version of Java one is supposed to install how on MacOS? Somehow, my El Captain as a 'Java for OS X 2015-001' disk on the desktop. Trying to install it results in some warnings that this is a legacy old version and one should download Java from java.com. Is that what I should be doing for building JPL? Is that what people who actually use Java on MacOS do? If I get it build, I might be able to add code to jpl.pl that automates the step above to fix the link target for libjpl.dylib. On 16:30, Jan Wielemaker wrote: As it seems the jpl build is now broken on my machine and it merely includes the old version, this seems a good time to look into this. Vmware for mac. The first question is which version of Java one is supposed to install how on MacOS? Somehow, my El Captain as a 'Java for OS X 2015-001' disk on the desktop. Trying to install it results in some warnings that this is a legacy old version and one should download Java from java.com. Is that what I should be doing for building JPL? Of 'Java for OS X 2015-001', Apple say: This package is exclusively intended for support of legacy software and installs the same deprecated version of Java 6 included in the 014-001 and 2013-005 releases. If you need Java, download the latest version of Java for OS X directly from Oracle Oracle's is kinda the reference implementation. For now, JPL should work fine with Java 6. Is that what people who actually use Java on MacOS do? Yes if they take Apple's advice;-) but I guess some will install the 'deprecated version of Java 6' because they (think they) need it, or because it's easier, then not install any newer version. If I get it build, I might be able to add code to jpl.pl that automates the step above to fix the link target for libjpl.dylib. Are you aiming to (be able to) build a binary SWI Prolog for Mac OS X x64 which happily links to either legacy Java 6 or recent Oracle/Sun Java 8?
0 Comments
Leave a Reply. |