>> - on Windows, Mingw gcj's jni doesn't use __stdcall for JNICALL, so there is >> calling convention mismatch when linking against non-mingw-gcj-recompiled >> JNI libs there >> This should not be true - we went out of the way to > get STDCALL support in the JNI implementation on > Win32, because we wanted to be binary compatible > with other JNI implementations (read Sun's) and > our users to expect GCJ-compiled programs to work > with pre-compiled third-party JNI libraries > (notably SWT). Actually I went back to the code and verified the following: - mingw gcj's jni.h does in fact define JNICALL to __stdcall - I have to redefine it to nothing after including <jni.h> otherwise I get an UnsatisfiedLinkError on one of the functions (Db_get) as soon as I try to use the library This happens with Berkeley DB 4.3.27's libdb_java, the SWIG generated JNI bindings for its db library. > If you find this to be not true, please file > a bug with a simple testcase. Did you find this > problem with a MinGW release or the one found > on Mohan's site (www.thisiscool.com)? Do you > also find the problem in vanilla FSF GCC sources? this is using Mingw 3.4.2 as downloaded from: . http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download . http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz . http://prdownloads.sf.net/mingw/gcc-g++-3.4.2-20040916-1.tar.gz . http://prdownloads.sf.net/mingw/gcc-java-3.4.2-20040916-1.tar.gz . http://prdownloads.sf.net/mingw/libiconv-1.8.0-2003年02月01日-1.exe I have never built my own gcc/gcj toolchain on Windows so I don't know the status of this problem in the vanilla sources. Andi..