octave-maintainers
[Top][All Lists]
Advanced

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

Re: Pre-compiling Java code for MXE build


From: Rik
Subject: Re: Pre-compiling Java code for MXE build
Date: Wed, 03 Jul 2013 07:32:56 -0700

On 07/03/2013 07:05 AM, address@hidden wrote:
Message: 6
Date: Wed, 3 Jul 2013 10:04:47 -0400
From: Michael Goffioul <address@hidden>
To: Anirudha Bose <address@hidden>
Cc: "John W. Eaton" <address@hidden>, PhilipNienhuis
	<address@hidden>,	Octave Maintainers List
	<address@hidden>
Subject: Re: Java support in MXE build
Message-ID:
	<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Jul 3, 2013 at 9:45 AM, Anirudha Bose <address@hidden> wrote:

> On Wed, Jul 3, 2013 at 6:51 PM, John W. Eaton <address@hidden> wrote:
>
>> On 07/02/2013 04:56 PM, Anirudha Bose wrote:
>>
>>> On Wed, Jul 3, 2013 at 2:18 AM, John W. Eaton <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>>     On 07/02/2013 04:38 PM, PhilipNienhuis wrote:
>>>
>>>         By the end of the week I might have time for this.
>>>         But I expect similar outcome as for Java, as IIRC I got exactly
>>>         the same
>>>         errors when building with llvm and no Java support, as when
>>>         building with
>>>         Java support and no llvm.
>>>
>>>
>>>     Sorry, I haven't been following this discussion carefully.
>>>
>>>     Are these problems for a native or cross build?
>>>
>>>     If not cross, then has anyone attempted a cross build with Java
>>> enabled?
>>>
>>>
>>> The problems are seen in both native as well as cross builds.
>>>
>>
>> When I do a cross build for mingw, I see the following messages in
>> log/octave:
>>
>>
>>   configure: WARNING: JAVA_HOME environment variable not initialized.
>>   configure: WARNING: Auto-detection will proceed but is unreliable.
>>   checking for java... /usr/bin/java
>>   /scratch/jwe/src/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-6-openjdk-**amd64/bin/javac
>>   checking for jar... /usr/lib/jvm/java-6-openjdk-**amd64/bin/jar
>>   checking for Java version... 1.6.0_27
>>   checking for jvm.dll... ls: cannot access
>> /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/*/client: No such file or
>> directory
>>
>>   not found
>>   configure: WARNING: Library jvm.dll not found.  Octave will not be able
>> to call Java methods.
>>
>
> Apparently jvm.dll is not available in OpenJDK. I used the Java
> installation from my Windows partition to get past this error.
>
>>
>> What packages are expected to be installed in order for Octave's
>> configure script to enable support for Java?  It seems to me that this
>> is something we should be doing automatically as part of the
>> mxe-octave build process, not something that must be done manually
>> before starting the build.
>>
>>
Something I meant to ask Anirudha to have a look at is whether it's
possible to cross-compile the octave/java support using a Linux JDK. In the
end, the code is not linked to any java library, it's actually only using
the headers and AFAIK, the java types are cross-platform. Some changes will
be needed (see below), but I think it's worth a try.
7/3/13

Anirudha,

This should be possible.  When I was working on porting the Octave-Forge Java package to core Octave I read two articles showing that the Java bytecode for the same section of code could be different depending on the compiler.  Nevertheless, there wasn't the suggestion that the code wouldn't run in a cross-platform way; Merely that
different compilers had chosen different techniques for translating certain Java language forms into slightly different bytecode sequences.

--Rik

Among the changes I foresee:
- under Linux, JNIEXPORT and JNICALL does expand to nothing; so one has to
make sure the right symbols are still exported properly, maybe by
overriding the macros with their Win32 definition (#define JNIEXPORT
__declspec(dllexport), #define JNICALL __stdcall)
- the octave configure script will still look for jvm.dll, though I don't
think it's necessary under Windows, as the JVM location will be retrieved
from the Windows registry

Michael.


reply via email to

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