Re: Java support in MXE build

[Michael Goffioul]

On Mon, Jul 1, 2013 at 5:40 PM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 5:36 PM, Michael Goffioul <address@hidden> wrote:

On Mon, Jul 1, 2013 at 5:10 PM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 4:03 PM, Michael Goffioul <address@hidden> wrote:

On Mon, Jul 1, 2013 at 3:34 PM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 11:45 PM, Michael Goffioul <address@hidden> wrote:

On Mon, Jul 1, 2013 at 10:32 AM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 8:24 AM, Michael Goffioul <address@hidden> wrote:

On Sun, Jun 30, 2013 at 11:31 PM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 3:12 AM, Michael Goffioul <address@hidden> wrote:

On Sun, Jun 30, 2013 at 5:12 PM, Anirudha Bose <address@hidden> wrote:

On Mon, Jul 1, 2013 at 2:39 AM, Michael Goffioul <address@hidden> wrote:

On Sun, Jun 30, 2013 at 5:06 PM, Anirudha Bose <address@hidden> wrote:

(previous message was bounced back as spam -- because of my shortened URL, maybe)

---------- Forwarded message ----------
From: Anirudha Bose <address@hidden>
Date: Mon, Jul 1, 2013 at 2:31 AM
Subject: Re: Java support in MXE build
To: Philip Nienhuis <address@hidden>, Michael Goffioul <address@hidden>
Cc: Octave Maintainers List <address@hidden>

On Sat, Jun 29, 2013 at 11:43 PM, Philip Nienhuis <address@hidden> wrote:

(maintainers list cc'd)

Anirudha Bose wrote:

On Wed, May 15, 2013 at 5:55 PM, PhilipNienhuis <address@hidden

<mailto:address@hidden>> wrote:

    Until now the MXE building process fails to include Java support.
    Looking at
    the log from a freshly checked out MXE build I see:

    configure: WARNING: JAVA_HOME environment variable not initialized.
    configure: WARNING: Auto-detection will proceed but is unreliable.
    checking for java... /usr/bin/java
    /home/philip/devel/octdev/mxe-octave/tmp-octave/octave-3.7.5/configure:
    line
    66352: pwd: -W: invalid option
    pwd: usage: pwd [-LP]
    checking for javac... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/bin/javac
    checking for jar... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/bin/jar
    checking for Java version... 1.7.0_19
    checking for jvm.dll... not found
    configure: WARNING: Library jvm.dll not found.  Octave will not be
    able to
    call Java methods.

    So the configure script defaults to the Linux Java system on the box
    where
    MXE is run.

    I then tried to configure with the Windows Java system, installed on
    another
    (windows 7) partition, by adding a few configure options in

    ./mxe-octave/src/octave.mk <http://octave.mk>   (symlink /mnt/jhm

    points to /mnt/win7/Program
    Files/Java/jdk1.7.0_21):

    :
             JAVA_HOME="/mnt/jhm" \
             --with-java-homedir="/mnt/jhm" \
             --with-java-libdir="/mnt/jhm/jre/bin/server" \

    --with-java-includedir="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/include"
    \
    :

    I had to make the symlink as configure hickups on spaces in path
    names. This
    trick seemed to work, but then I got other errors:

    :
    - checking for java... /usr/bin/java
    /home/philip/devel/octdev/mxe-octave/tmp-octave/octave-3.7.5/configure:
    line
    66352: pwd: -W: invalid option
    pwd: usage: pwd [-LP]
    checking for javac... /usr/bin/javac
    checking for jar... /usr/bin/jar
    checking for Java version... 1.7.0_19
    checking for jvm.dll... /mnt/jhm/jre/bin/server
    checking for include file <jni.h>... not found
    configure: WARNING: Include file <jni.h> not found.  Octave will not
    be able
    to call Java methods.
    :

    Setting JAVA_HOME to the Java installation on the Windows partition
    doesn't
    help in any way.

    So it seems the configure script consistently picks up the native
    (Linux)
    Java version and seems to largely ignore the --with-java-* configure
    options. It does find the jvm.dll (that configure option works) but not
    jni.h while the latter does live in the "java-includedir" indicated
    in the
    configure options.

    Obvious question: how can we proceed with getting Java support
    included in
    MXE builds?

    Philip


Hey Philip. Can you send me your copy of src/octave.mk

<http://octave.mk>. I am also working on getting Java enabled in MXE but

presently stuck with "Library jvm.dll not found". Is it possible to get
Java enabled in cross builds? The Linux system from which we are
compiling surely doesn't contain any DLL files, and the only obvious
option is to use the Java installation of Windows.

(Sorry short answer, I have other plans this weekend)

Read my last posting in that thread.

I had configure options pointing to the Windows-installed Java JDK.
Watch out for 64-bit vs 32-bit Java (client vs server subdir in the JDK).

I simply added the relevant configure options to the octave.mk file (+ symlinked a few things), and then the configure script picked up the proper Java stuff (i.e. the JDK on the Windows side on that machine).

However I soon ran into more obscure problems that I reported earlier in the maintainers ML:

https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-May/033675.html

(i.e., the errors starting with dldfcn/.libs/__dsearchn__.o: In function `~octave_base_value':

/home/philip/devel/octdev/mxe-octave/tmp-octave/octave-3.7.5/libinterp/octave-value/ov-base.h:211: undefined reference to `vtable for octave_base_value'

etc
etc)

I suppose the symlink / configure option trick (for cross-compiling) itself worked OK, as in later native MXE-MinGW build I got exactly the same error messages. Same for a development tip building with the MXE-built dependencies. I the post I linked to above I also reported the same issue that I got with MinGW builds earlier on. Perhaps something is wrong with the Java configure options for MinGW.

Anyway, that's how far I got.

Philip

I could get Java enabled in my build, but getting the same errors you have described. For the sake of being specific, here are the errors I got: http://fpaste.org/22028/62600013/

Could you also paste the actual link command?

  

http://fpaste.org/22028/62600013/ 

I don't see the link command in there.

Sorry for the confusion. I mistook link to be URL. I have written all the details in my blog post. By "link command" if you mean the options used in configure to link to Java SDK, then they are --with-java-homedir="/c/Java/jdk1.7.0_25" --with-java-includedir="/c/Java/jdk1.7.0_25".

No, I really meant the link command. When you compile software, you first compile the source files into objects files, then you link everything together to produce the executable. This last step is what I call the link command. From the errors you reported, it appears there are undefined references, I want to check the link command to see whether it's missing anything.

Ok I understood what is a link command. Perhaps you will it in the complete log of octave. Download it here (online paste tools do not allow such huge sized logs): https://docs.google.com/uc?export=download&id=0ByU28MYPGBpodk5ha0oxSmoyOVk

Could you try the following:

./usr/bin/i686-pc-mingw32-nm tmp-octave/octave*/libinterp/.libs/liboctinterp.dll.a | grep check_version

(Note: you may need to adapt the paths above to locate liboctinterp.dll.a in the temporary octave source tree)

I think there is a possible mismatch here. The file ./usr/bin/i686-pc-mingw32-nm doesn't exist in native builds, and the file liboctinterp.dll.a doesn't exist in cross builds. Perhaps you meant something else by ./usr/bin/i686-pc.... 

I was talking about the cross-compilation case. Even when cross-compiling, liboctinterp.dll.a does exist. However, because your octave compilation fails, it's not installed and is still located somewhere in the octave temporary source tree, in tmp-octave/ subdir.

Okay. I completed the cross-compile (till I got the error), and now I can see the file liboctinterp.dll.a in this path:
    tmp-octave/octave-3.7.5/.build/libinterp/.libs/liboctinterp.dll.a

So the command I issued was this:
    ./usr/bin/i686-pc-mingw32-nm tmp-octave/octave-3.7.5/.build/libinterp/.libs/liboctinterp.dll.a | grep check_version

The output was blank (nothing). Did I do something wrong, or this is what you wanted to check?

This explains the link error, but I'm wondering why the hell some symbols are missing... Do you get anything with:

./usr/bin/i686-pc-mingw32-nm tmp-octave/octave-3.7.5/.build/libinterp/.libs/liboctinterp.dll.a | grep ' T '

Yes. I got the following output:

00000000 T address@hidden
00000000 T address@hidden
00000000 T address@hidden
00000000 T address@hidden
00000000 T address@hidden

Ok, I think I figured out the issue. This is better explained here [1]. Basically, the linker export all symbols by default. When --export-all-symbols is not explicitly given on the command line, it may not export all symbols if some symbols are marked with dllexport. And this is the case when you enable Java support, through the JNIEXPORT macro in ov-java.cc. As a result, you end up with a DLL where *only* the JNI functions are exported.

The fix would be to make octave keep the -Wl,--export-all-symbols on the link command for MinGW. Does anyone (John?) know why it's not being kept? I can see the following in configure output:

configure: defining SH_LDFLAGS to be -shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-auto-image-base

But those arguments do not appear in the final link command. Another option would be to activate the XXX_API macros for MinGW, like it's done for MSVC.

Michael.

[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html