Re: load native lib (SWT) with JNI on windows

[Ranjit Mathew <rmathew at vsnl dot net>]

Tom Tromey wrote:
> Ranjit> In any case, it turned out that the SWT DLL exports
> Ranjit> JNI native methods as "_Java_foo_Bar" as opposed to
> Ranjit> all the GCC created DLLs that I'd been working with all
> Ranjit> the while that export JNI native methods as "Java_foo_Bar".
> Ranjit> So I had to modify LookupJNIMethod (jni.cc) with a kludge
> Ranjit> where it first looks for "Java_foo_Bar" and then (only
> Ranjit> for Windows) looks for "_Java_foo_Bar".
>
> This is interesting.  Is adding a `_' part of the Windows ABI?  If so,
> does gcc not follow it on purpose?  It seems to me that perhaps
> libltdl ought to take care of this detail for libgcj.  If not (there's
> good arguments on either side, I guess), we can add a platform-neutral
> "need to add _" #define to libgcj.

A bit of research on the web turned up the reason for this
state of affairs - Microsoft and Borland have decided to
follow different conventions for exporting "stdcall" and "cdecl"
(the default calling convention) functions from a DLL. The
following article contains some useful introductory
information:

http://www.bcbdev.com/articles/bcbdll.htm#introduction

In particular, the following table from the article
summarises the situation:
--------------------------------- 8< ----------------------------------
Calling convention  VC++ name       VC++ (DEF used)     C++Builder Name

__stdcall           _MyFunction@4   MyFunction          MyFunction
__cdecl             MyFunction      MyFunction          _MyFunction
--------------------------------- 8< ----------------------------------

To complement the situation perfectly, the MinGW ld omits the
underscore in both the cases and adds the @nn for stdcall
functions.

Therefore, for a given JNI method fooBar( ) implemented in a DLL,
the LookupJNIMethod( ) function must search for all of
"fooBar@nn" (GCC), "_fooBar@nn" (MSVC) and "fooBar" (BCC).
(Assuming these are the only compilers we care to support.)

This is just the short name - if all of these searches are
unsuccessful, it must then use the long name (with full type
info), with all these variations of course, to look up the
function.

And judging by the code for FindSymbolInExecutable( ), this
set of operations would be performed for each of the loaded
libraries in turn in the worst case.

Ah B-L-I-S-S!

:-(

Sincerely Yours,
Ranjit.

--
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,
INDIA.               Web: http://ranjitmathew.tripod.com/