views:

77

answers:

1

Namely, a DLL name has an extra @8 at the end which is causing trouble. Apparently, using the --kill-at flag in gcc would solve this, but I can't find any similar suggestions for MSVC.

EDIT: A little more info:

I'm trying to get a C++ JNI dll to work, but I constantly get Exception in thread "Thread-0" java.lang.UnsatisfiedLinkError: eveTimers.PollThread.checkKeyboardChanges()V back instead of a functioning program. I used quickview to look at the dll and discovered it's decorated with @8 which http://www.velocityreviews.com/forums/t143642-jni-unsatisfied-link-error-but-the-method-name-is-correct.html suggests is a possible problem. Help would be greatly appreciated.

+1  A: 

[Edited out as irrelevant, per comment below].

Another approach is to specify export names in a .DEF file.

Your calling convention and linker settings can affect this as well. It's a bit of a black art, to be honest. Use MSVC for a dozen years and you'll still occasionally run into pesky name-mangling issues that should be easy to fix, but are non-trivial to actually fix, given how the different settings interact.

James D
Only the .DEF file will let you completely prevent mangling. The other methods suffix @(byte count of arguments) to stdcall functions and prefix _ to cdecl functions.
Ben Voigt
Of course, it's not quite that simple. There are scenarios where you can go the .DEF file route and find that your names are still being mangled. The solution as always for this kind of thing is to actually understand the MSVC link stage--in my experience, a non-trivial proposition for people approaching from other environments.
James D