Re: Java support in MXE build

[PhilipNienhuis]

Michael Goffioul wrote
> On Mon, Jul 1, 2013 at 5:40 PM, Anirudha Bose <

> ani07nov@

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

> michael.goffioul@

>> wrote:
>>
>>> On Mon, Jul 1, 2013 at 5:10 PM, Anirudha Bose &lt;

> ani07nov@

> &gt; wrote:
>>>
>>>>
>>>> On Mon, Jul 1, 2013 at 4:03 PM, Michael Goffioul <
>>>> 

> michael.goffioul@

>> wrote:
>>>>
>>>>> On Mon, Jul 1, 2013 at 3:34 PM, Anirudha Bose &lt;

> ani07nov@

> &gt;wrote:
>>>>>
>>>>>>
>>>>>> On Mon, Jul 1, 2013 at 11:45 PM, Michael Goffioul <
>>>>>> 

> michael.goffioul@

>> wrote:
>>>>>>
>>>>>>> On Mon, Jul 1, 2013 at 10:32 AM, Anirudha Bose &lt;

> ani07nov@

> &gt;wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 1, 2013 at 8:24 AM, Michael Goffioul <
>>>>>>>> 

> michael.goffioul@

>> wrote:
>>>>>>>>
>>>>>>>>> On Sun, Jun 30, 2013 at 11:31 PM, Anirudha Bose &lt;

> ani07nov@

> &gt;>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 1, 2013 at 3:12 AM, Michael Goffioul <
>>>>>>>>>> 

> michael.goffioul@

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

> ani07nov@

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

> michael.goffioul@

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

> ani07nov@

>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (previous message was bounced back as spam -- because of my
>>>>>>>>>>>>>> shortened URL, maybe)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>> From: Anirudha Bose &lt;

> ani07nov@

> &gt;
>>>>>>>>>>>>>> Date: Mon, Jul 1, 2013 at 2:31 AM
>>>>>>>>>>>>>> Subject: Re: Java support in MXE build
>>>>>>>>>>>>>> To: Philip Nienhuis &lt;

> pr.nienhuis@

> &gt;, Michael Goffioul
>>>>>>>>>>>>>> &lt;

> michael.goffioul@

> &gt;
>>>>>>>>>>>>>> Cc: Octave Maintainers List &lt;

> octave-maintainers@

> &gt;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Jun 29, 2013 at 11:43 PM, Philip Nienhuis <
>>>>>>>>>>>>>> 

> pr.nienhuis@

>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (maintainers list cc'd)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anirudha Bose wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, May 15, 2013 at 5:55 PM, PhilipNienhuis <
>>>>>>>>>>>>>>>> 

> pr.nienhuis@

>>>>>>>>>>>>>>>> &lt;mailto:

> pr.nienhuis@

> &gt;**> 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 &lt;http://octave.mk&gt;
>>>>>>>>>>>>>>>> (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
>>>>>>>>>>>>>>>> &lt;http://octave.mk&gt;. 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&lt;https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-May/033675.html&gt;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (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.

Note that the same happens when llvm is enabled (with the --enable-jit
configure option in MXE builds). 
I described this as well in the original post on the maintainers ML.

So, does llvm also have macros stripping out these linker flags?

Philip



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Java-support-in-MXE-build-tp4652996p4655098.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.