octave-maintainers
[Top][All Lists]
Advanced

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

Re: Java support in MXE build


From: Michael Goffioul
Subject: Re: Java support in MXE build
Date: Tue, 2 Jul 2013 08:17:13 -0400

On Tue, Jul 2, 2013 at 7:09 AM, PhilipNienhuis <address@hidden> wrote:
>>> ./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?

Note that it's not stripping linker flags. In the case of Java, it's just the linker behaving differently when it sees dllexport in the object files (it doesn't do automatic symbol export). For LLVM, I'm not sure. Try to run the "nm" command above to see what symbols are exported by liboctinterp.dll.a.

Michael.


reply via email to

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