views:

45

answers:

2

So I'm trying to get this nuclear instrumentation hardware to work.

I have installed 64 bit drivers (I'm using Windows 7 64 bit) and I have downloaded the dll's that go with it.

When I add the dlls and try to use the functions in a win32 console application project in visual studios, it gives me a linker error:

Error 1 error LNK2019: unresolved external symbol _CAENVME_SWRelease@4 referenced in function _main main.obj vmeTest

Which I suppose means it can't find the function CAENVME_SWRelease in the dll.

I have added the dll and corresponding .lib to the project along with the header files and added them to the references (I have tried adding them to the path environment variable and under the linker in additional library directories <--not had to do that before but thought I would try) but it just won't work.

To see if I just wasn't doing it right, I tried creating a dll and adding it to the project the same way, and it works fine.

So I was wondering if perhaps it is because I'm using a win32 project and these dlls are 64 bit (because they are for 64 bit drivers?).

Obviously I don't know what I'm talking about. Could anyone give me some assistance or take a stab at what might be going on?

Here's how the function is defined in the header file:

CAENVME_API
CAENVME_SWRelease(char *SwRel);

and I called it like this:

char dog;
CAENVME_SWRelease(&dog);
cout << dog
+1  A: 

In the symbol name _CAENVME_SWRelease@4, the '@4' is the length of the arguments on the stack in bytes - 4 bytes for a 32-bit pointer. On 64-bit this will be 8 bytes, and so the function will be mangled to '@8' which is why the name resolution fails.

[At least it would it 64-bit stdcall got mangled the same way as 32-bit, but it doesn't. In any case there are now enough registers to pass the first few args in registers so this won't end up on the stack, and it's important that the caller and callee agree about the number of bytes on the stack to be cleaned up in stdcall (callee cleans) so that's the source of the number in the name-mangling. Thanks Hans!]

But no, even if you do get this right you can't link 32-bit and 64-bit code together like this. Sorry.

Aside: I suspect you actually want

char SwRel[256];
CAENVME_SWRelease(SwRel);

I suspect it's going to fill in a buffer with a string rather than return you a single character. However that's not really on given it doesn't accept a buffer size parameter, so all you can do is deliberately aim high with the buffer size.

Rup
The 64-bit stdcall name decoration doesn't use the @n postfix, the argument is passed through a register. Otherwise agreed, the OP needs to link the 32-bit version of the .lib or build the x64 version of his program.
Hans Passant
D'oh, yes. I haven't dug around 64-bit Windows much.
Rup
So will the 32-bit version of the .lib be able to control the 64 bit drivers I have installed (obviously I can't install 32 bit drivers) or is the only option to code my program in 64 bit? The 32-bit version of the library is available. Thanks for the responses by the way.
Johnny
A: 

Into you project you must add another "target" add a x64 destination this will help you.

but you must have 64bits of all libraries that you use.

check here for more information, take care about pointers (is a nightmare but possible)

http://msdn.microsoft.com/en-us/library/aa384204.aspx

Gustavo V