>>> > 11/18/13
>>> > >>> > I downloaded a copy of Java for Windows XP and every time I try
>>> > in
>>> > Octave (built with MXE) I get a panic and segfault. Is this something
>>> > about the new Java (1.7) from Oracle, or is it with Octave?
>> What copy of Java did you download & install? A JDK, a JRE?
>>>> Here I've built and used Java support with (cross-built) MinGW binaries
>> since I figured out how to get Java support cross-compiled in mxe-octave.
>> described that in the maintainers ML (IIRC somewhere in July).
>>>> Don't know if it helps but my octave.mk has been attached.
>> You'd need to adapt the SHA1 checksum and configure settings. Note that I
>> simply copied the contents of Windows
> /include/win32/ to Linux
> /include (a kludge, but I think a decent one at that, for the
> > 11/27/13
> > This problem is still very much present for me. I have done nothing
> special either on the Linux side or the Windows side.
I expect that you'll have no Java support compiled in then. See below.
> On the Linux side, I
> have Java installed and when I run the MXE cross-build it succeeds.
Sure, but without Java support.
> On the
> Windows side I have Windows XP and I just downloaded the standard package
> from Oracle which gives me Java 7 Update 45 (probably just a JRE). I get
> segfault every time when using any Java command.
> > It seems to me that we may need to be more careful in configure.ac about
> distinguishing between $build_os and $host_os. We require a Java
> environment on the $build_os in order to produce .class and .jar files
> are a part of Octave. We require a jvm on the $host_os in order to run
> things, but we can't test that in a cross-compiling situation and should
> just assume "yes".
> > For any Java experts, is it possible that the problem is architecture
> related (32-bit vs. 64-bit). My build platform is x86_64 Linux, but
> Windows XP Home Edition is 32 bit.say about
Maybe it is indeed 64 vs 32 bit. I don know, I cross-build Octave on a
32-bit Linux box (didn't have time to install 64-bit Linux yet).
I'm inclined to think that this is not an issue now. I compiled a
Hello World example on the Linux side and copied the resulting
bytecode across to the Windows side and it works there. There still
is the possibility of something being different because of the JNI
interface, but lower probability.
What does the octave build log, especially the configure step, in mxe say
about Java? (in ./log/octave)
Yeah, I had checked that early on in trying to diagnose this and it
definitely says that Java was detected and the the summary reports
that the Java interface is being built.
AFAIK, if you have no Java include files for Windows on the Linux side
(either using my trick, or somewhere in ./tools/ like Anirudha did) one gets
configure messages that jni_md.h wasn't found and Java support won't be
Here, trying Java methods with such an mxe-octave binary on Windows would
give messages that Java support wasn't compiled in, but no segfaults.
I added a --disable-java option to MXE and have been using that for
about a week to get around this issue for testing. When Java is not
built in, I get the same messages as you and no segfaults.
I'm going to rebuild with debugging enabled and see what happens.