Mon 04 Apr 2016 04:39:58 PM UTC, comment #7:
Answer 1:
32-bit Octave (based on comparing octave-4.0.1-cli.exe's time stamps in the installer and in OCTAVE_HOME/bin I think the existing one from ftp.gnu.org):
Octave-4.1.0+ (64bit) shows the same PATH with "Octave32-4.0.1" replaced by "Octave-4.1.0+_w64VEtst"
============================================
Answer 2:
Using the io package's scripts:
octave-4.0.1 32-bit does this:
and
The LibreOffice UNO-Java bridge (belonging to LO, not stuff in the io package!) contains several compiled procedures so LO just doesn't work if Octave has a different "bit width", even if the io package finds the LO java parts and added them to the javaclasspath.
Octave can only find out if it "matches" by trying.
Now, with 64-bit Octave-4.1.0+
(so runs fine) and
so each version (32bit and 64bit) of Octave picks up the matching Java version.
One question now is: did JWE build the 32-bit installer with a 32-bit or a 64-bit JDK on his Linux box?
AFAICS 32-bit or 64-bit Octave doesn't make a difference as regards 32-bit or 64-bit Java JRE when just invoking methods from ready-baked Java class libs . jar files) in the javaclasspath.
Admittedly a 32-bit Java JRE implies a smaller JVM heap than that of a 64-bit Java JRE, as shown above in the verbatim blocks.
|