_fnAmosMoses@0 is __stdcall name encoding, where the arguments' stack
size is appended with "@NN". StdCallFunctionMaper should work in this
case, although some have reported problems with it not picking up the
leading underscore.
Try modifying StdCallFunctionMapper to prepend a leading underscore,
see if that helps. I've tried to generate symbols with a leading
underscore (with gcc and msvc) to no avail; maybe you have to compile C
++ code?
Let me know what happens.
T.
On Apr 9, 2008, at 3:44 AM, Ewan Slater wrote:
<quote>
if they are plain functions (as opposed to class methods) you can put
extern "C" in front of the fucntion declarations inthe c++ code and
that
will turn the name mangling off
</quote>
Tried that...and the level of mangling definitely comes down.
In my dll (using the dependency tool) I used to get...
?fnAmosMoses@@YGHXZ
...(mapping the mangled name directly worked just fine) and now I
get...
_fnAmosMoses@0
which I hoped would work with the StdCallFunctionMapper.
But I still get UnsatisfiedLinkError!
So, am I doing something daft (code follows)?
calling code:
public static void main(String[] args) {
HashMap optionMap = new HashMap();
StdCallFunctionMapper mapper = new StdCallFunctionMapper();
optionMap.put(Library.OPTION_FUNCTION_MAPPER, mapper);
//optionMap.put("fnAmosMoses","?fnAmosMoses@@YGHXZ"); //from
dependency tool
AmosMosesLib amos = (AmosMosesLib)
Native.loadLibrary("AmosMoses", AmosMosesLib.class, optionMap);
int amosSays = amos.fnAmosMoses();
System.out.println("Amos says " + amosSays);
}
interface:
public interface AmosMosesLib extends Library {
int fnAmosMoses();
double doubleD(double d);
}
Declaring code
#define AMOSMOSES_API __declspec(dllexport)
extern "C" AMOSMOSES_API int fnAmosMoses();
extern "C" AMOSMOSES_API double doubleD(double d);
Cheers,
Ewan
9 messages in net.java.dev.jna.usersRe: [jna-users] Re: C++ StdCallFuncti...
