[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Java support in MXE build
From: |
PhilipNienhuis |
Subject: |
Re: Java support in MXE build |
Date: |
Tue, 2 Jul 2013 04:09:13 -0700 (PDT) |
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 <
> ani07nov@
> > 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 <
> ani07nov@
> >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 <
> ani07nov@
> >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 <
> ani07nov@
> >>>>>>>> > 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 <
> ani07nov@
> >
>>>>>>>>>>>>>> Date: Mon, Jul 1, 2013 at 2:31 AM
>>>>>>>>>>>>>> Subject: Re: Java support in MXE build
>>>>>>>>>>>>>> To: Philip Nienhuis <
> pr.nienhuis@
> >, Michael Goffioul
>>>>>>>>>>>>>> <
> michael.goffioul@
> >
>>>>>>>>>>>>>> Cc: Octave Maintainers List <
> octave-maintainers@
> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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@
>>>>>>>>>>>>>>>> <mailto:
> pr.nienhuis@
> >**> 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<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.
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.
- Re: Java support in MXE build, Michael Goffioul, 2013/07/01
- Re: Java support in MXE build,
PhilipNienhuis <=
- Re: Java support in MXE build, Michael Goffioul, 2013/07/02
- Re: Java support in MXE build, PhilipNienhuis, 2013/07/02
- Re: Java support in MXE build, John W. Eaton, 2013/07/02
- Re: Java support in MXE build, Anirudha Bose, 2013/07/02
- Re: Java support in MXE build, John W. Eaton, 2013/07/03
- Re: Java support in MXE build, Anirudha Bose, 2013/07/03
- Re: Java support in MXE build, Michael Goffioul, 2013/07/03
- Re: Java support in MXE build, John W. Eaton, 2013/07/03
- Re: Java support in MXE build, PhilipNienhuis, 2013/07/03
- Re: Java support in MXE build, John W. Eaton, 2013/07/03