octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Success: core Java support in MXE build


From: Philip Nienhuis
Subject: Re: Success: core Java support in MXE build
Date: Wed, 25 Sep 2013 20:39:25 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

John W. Eaton wrote:
On 07/11/2013 12:15 PM, PhilipNienhuis wrote:

A few days ago I succeeded both with building Octave with built-in java
support on MinGW and cross-compiling it (MXE) on my Linux box.
Cross-compiling is as follows: (beware it's a bit of a kludge just
meant as
a proof-of-concept)


1. Patch configure.ac to add "-Wl,--export-all-symbols" to the load
flags in
the mingw section (bug# 39454). This is required for any mingw Octave
build.
(There's some discussion whether this is the best fix - for including
core
Java support it is OK but other MinGW packages may need another place for
this fix.)

Fixed on default (see below).
Michael G. is still a bit unsatisfied (with good reason, see above) but for this very issue (Java on MinGW/MXE) the fix suffices.

2. Make sure the platform-dependent jni_md.h can be found.
## Kludge warning:
## I copied<Windows><jdk>/include/win32/ subdir + contents over to my
## Linux<jdk>/include subdir.
## I also did a "touch jvm.dll" somewhere (actually in
##<Linux_JDK>/jre/lib/i386/client) to comfort configure that
## complained it couldn't find jvm.dll.
## (I think this is a bug in configure)
Add the following in<mxe-octave>/src/octave.mk in the configure section:
--with-java-includedir=</full/path/to/linux/jdk> ## Omit include/ subdir
in this path!
--with-java-libdir=</full/path/to/some/place/with/dummy/jvm.dll>
(maybe on MingW/native build:)
--with-java-homedir=</full/path/to/jdk> ## Not sure if this is needed


(3. If you want the latest dev version, build a "make all dist"
octave-<version>.tar.gz, copy it over to<mxe-octave>/pkg, do "openssl
sha1
octave-<version>.tar.gz" and substitute the checksum in
<mxe-octave>/src/octave.mk)


4. Run ./mk-dist<options>
When cross-compiling on Linux Octave's configure will probably find the
javac and jar executables from the build platform.
When building on MinGW, JAVA_HOME should be set properly.


Things to improve:

A. Find out if we could just dld/copy the contents of<jdk>/include&
<jdk>/include/win32, or download them from theURLs Michael gave above,
and
point --with-java-includedir= to it.

Which header files do we actually need? What does Octave include
directly? Is it just jni.h or are more files required? What (if any)
other header files are included from those files?

Only those two.
In fact we even may only need the platform-specific win32/jni_md.h, as jni.h doesn't really differ between Linux and Windows. But using them as a pair is probably the safest and easiest choice.

B. Fix configure / configure.ac so that it doesn't try to find jvm.dll
for
MinGW builds, so that the dummy jvm.dll can be avoided. I'll enter a bug
report for this.

To make it easier to find, it looks like the report is here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=39465

Fixed by Anirudha in his GSOC MXE branch (see below).

So to have java support built-in with mxe-octave for a Windows Octave
binary, I conclude the following tools and files are needed:

- A Java JDK. Or more precise, javac and jar executables + their possible
implicit dependencies.

For cross compiling can we use the javac and jar executables for the
build system to generate the files for the host system (i.e., run the
Debian javac and jar programs to generate files for MinGW)?

Yes.

- jni.h + win32/jni_md.h

I guess this answers my question above. Are these files distributed
under terms that would allow us to include fallback copies in the Octave
or mxe-octave sources if they aren't installed on the build system?

This has been touched upon a bit later in this thread: the files are GPL 2 with the "classpath exception". Upon first reading the latter -but IANAL- I get the impression that we're OK with using them for building and distributing the installer. But I'm not confident we may include the header files themselves. AFAICS it revolves around interpretation of the phrase "...linking this library with independent modules to produce an executable..." - is the executable the installer (could be)? or just the compiled ov_java.cc embedded in liboctave?

Thanks for working on this issue.

My pleasure.
In turn, thanks again for making MXE possible.

Has there been any other progress? I'd
like to try to fix Octave's configure.ac file and also revise the
mxe-octave makefile and scripts so that things work properly and without
a lot of things needing to be done manually.

A fix for the configure flags was already pushed to default (Octave) a while back (http://savannah.gnu.org/bugs/index.php?39454)
That's about all as far as the default branch goes.

AFAICS in his own GSOC development branch Anirudha has fixed bug #39465, + a few others. The wait is for merging in Anirudha's branch.


Note that I do not use the latest MXE. Cross-building with OpenBLAS using MXE 0.0.11 doesn't succeed on my box due to a compile error with "dllwrap not found":
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-August/035883.html
Because:
- Anirudha is still busy with MXE,
- I didn't want to interfere with his work, and
- my somewhat modded MXE-0.0.3 still works OK for me,
I just left this issue aside - apparently Anirudha and John D. didn't hit this, so I figured it could be specific for my setup. As soon as Anirudha's branch is absorbed in the "official" MXE repo I'll try again.

Philip


reply via email to

[Prev in Thread] Current Thread [Next in Thread]