Loadlibrary problems with const object

I'm trying to load some .dll library functions for a camera driver into Matlab using the loadlibrary command without success. I'm using Win7 x64, running R2011a. Also, I have MS Visual Studio 2010 pro as the compiler. I've tried running this from both the matlabroot directory, as well as the directory containing the .dll and .h files (which has been added to the search path), and I'm running Matlab as administrator.

If I run this simple script:

dllfile = 'C:\Program Files\Andor SOLIS\Drivers\atmcd64d.dll';
hfile = 'C:\Program Files\Andor SOLIS\Drivers\ATMCD32D.H';
[nofound,warn] = loadlibrary(dllfile,hfile);

I get the following error stream:

??? Error using ==> loadlibrary at 441
Building atmcd64d_thunk_pcwin64 failed.  Compiler output is:
cl -I"C:\Program Files\MATLAB\R2011a\extern\include"  /Zp8  /W3
/D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_DEPRECATE /D_SECURE_SCL=0
/nologo  -I"C:\Program Files\Andor SOLIS\Drivers" -I"C:\Program Files\Andor
SOLIS\Drivers" "atmcd64d_thunk_pcwin64.c" -LD
-Fe"atmcd64d_thunk_pcwin64.dll"
atmcd64d_thunk_pcwin64.c
atmcd64d_thunk_pcwin64.c(1284) : warning C4114: same type qualifier used
more than once
atmcd64d_thunk_pcwin64.c(1284) : error C2166: l-value specifies const object

Any ideas?

-Jesse

 [nofound,warn] = loadlibrary(dllfile,hfile);

Answer 1

[Kaustubha Govind]

If you are using 64-bit MATLAB, you must ensure that you are loading a 64-bit DLL. From the names of your files: atmcd64d.dll and ATMCD32D.H, it seems that the DLL is 64-bit, but the header file you are using to load it for the 32-bit version of the library. Could you verify if that is the case (the name doesn't necessarily tell us anything, so you can use the dumpbin utility with the /headers option to verify whether you have a 64-bit binary)? Are you able to load this DLL is a 64-bit C/C++ application outside of MATLAB?

[Jesse]

thanks for the info -- yes, the .dll here is a 64-bit binary. My impression was that the header file would work for either the 32 or 64 bit versions, as the function defs should be the same? As far as i know, the manufacturer for this camera didn't supply a "64 bit" header?

[Kaustubha Govind]

I suppose the same header could be used (unless some datatypes change?). I've kind of run out of leads at this point - could you try using writing a simple application is Visual Studio using LoadLibrary() to see if the library can be loaded successfully outside of MATLAB? That will help us narrow it down to a DLL/MATLAB issue. If it is a MATLAB issue, you could then contact Tech Support about it.

[Vijay]

I'm also getting stuck on using the atmcd64d.dll from 64-bit Matlab via loadlibrary, with exactly the same compiler error (C2166: l-value specifies const object).

The supplier of this DLL (Andor) makes clear in their documentation that the atmcd32d.h header is meant to work with both the 32- and 64-bit versions of their DLL.

I'm curious to know if there's been any further progress by Jesse in trying to load atmcd64d.dll into 64-bit Matlab via loadlibrary?

Vijay Iyer

HHMI/Janelia Farm

Answer 2

[Vijay]

Actually, I've just been able to successfully create the thunk file needed for 64-bit loadlibrary() operation.

The issue is with the OA_xxx functions in the amcd32d.h file. They use function signatures like: OA_Initialize(const char * const pcFilename,...)

The doubled-up use of const makes the compiler unhappy.

In general, the thunk-file generator for 64-bit loadlibrary is quite sensitive to syntax in header files that often worked under 32-bit loadlibrary(). In part it's because it requires strict C syntax. So generally, the header files have to be massaged to allow the thunk file generation to proceed. This was a new one for me.

In this case, those OA_xx functions are somewhat ancillary, so I just commented them out. If you need those functions, some signature change would be needed in the header to allow the loadlibrary() thunk file gen to work.

[Ofek]

My own personal solution when confronting a very similar solution was to hijack and massage the generated thunk source. It seems that always (or nearly always?) just renaming the generated file to cpp and building it as such generates a valid thunk dll, which leaves one wondering why it was generated as a .c file in the first place.