On Jun 14, 2007, at 2:53 PM, Daniel Horowitz wrote:
I changed my function to __stdcall
extern "C" __declspec(dllexport)int __stdcall subscribe(int foo);
int __stdcall subscribe(int foo)
{
return 0;
}
and I changed my java interface to extend Library
Now I am getting -
Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot
locate function 'subscribe'
Slow down, Tonto.
If your functions are stdcall, use StdCallLibrary. If they're not,
use Library. Don't mix. Unless you have a reason to make them
stdcall, don't. Your build, linkage, and interop will be simpler.
If you decide you really need stdcall, when building your dll, the
default symbol exported for the above function is subscribe@4. If
you're using the latest trunk build, you can add the
StdCallFunctionMapper to the options passed to Native.loadLibrary, e.g.
interface MyLibrary extends StdCallLibrary {
MyLibrary INSTANCE = (MyLibrary)Native.loadLibrary("mylib",
MyLibrary.class, new HashMap() {{ put(OPTION_FUNCTION_MAPPER,
FUNCTION_MAPPER); }});
...
The reason you don't have to do this for w32 API dlls is that
microsoft has exported undecorated versions ("subscribe" rather than
"subscribe@4") of all the functions. You can also do this by using a
DEF file to define the symbols you want exported in your link step
(don't know if VS2005 has any IDE magic to do so, though).
13 messages in net.java.dev.jna.usersRe: [jna-users] Cannot pass any data ...
