Thread Subject:

Compiling mex function with link to external library - linking errors

Hello,

I'm trying to compile a mex function that links to an external library. It is failing, being unable to find the "symbols" to the library function calls. I've spent an embarrassing amount of time trying to figure this out and any help would be greatly appreciated. Here's what I've got:
----------
>> mex('gsf_Read.c','.\gsf_0303\WinGSF\Debug\WinGSF_lib.lib')
   Creating library C:\Users\vschmidt\AppData\Local\Temp\mex_p5d3gD\templib.x and object C:\Users\vschmidt\AppData\Local\Temp\mex_p5d3gD\templib.exp
gsf_Read.obj : error LNK2019: unresolved external symbol gsfClose referenced in function mexFunction
gsf_Read.obj : error LNK2019: unresolved external symbol gsfRead referenced in function mexFunction
gsf_Read.obj : error LNK2019: unresolved external symbol gsfOpen referenced in function mexFunction
gsf_Read.mexw64 : fatal error LNK1120: 3 unresolved externals
 
  C:\PROGRA~1\MATLAB\R2011B\BIN\MEX.PL: Error: Link of 'gsf_Read.mexw64' failed.

-----------------

gsfOpen, gsfRead and gsfClose are the library function calls.

I can the cygwin/linux utilty "nm" to dump the symbol table from the library. When I do I see that the function calls are defined with a leading underscore (e.g. _gsfRead). This may be the problem. I read that the leading underscore is a convention common to windows and found an option in the Visual Studio build configuration called "Calling Convention" which passes options _cdecl (/Gd) or _stdcall (/Gz) to the compiler, the former of which is *supposed* to omit the leading underscore. However if I select this (it was the default) the leading underscore remains and in any case I read elsewhere that the compiler and linker are supposed to be smart enough to associated _gsfRead with gsfRead.

So I remain stumped. I completely appreciate any thoughts.

-Val

"Val Schmidt" wrote in message <jn6vev$o52$1@newscl01ah.mathworks.com>...

>
> I can the cygwin/linux utilty "nm" to dump the symbol table from the library. When I do I see that the function calls are defined with a leading underscore (e.g. _gsfRead). This may be the problem. I read that the leading underscore is a convention common to windows and found an option in the Visual Studio build configuration called "Calling Convention" which passes options _cdecl (/Gd) or _stdcall (/Gz) to the compiler, the former of which is *supposed* to omit the leading underscore. However if I select this (it was the default) the leading underscore remains and in any case I read elsewhere that the compiler and linker are supposed to be smart enough to associated _gsfRead with gsfRead.

I don't think it's safe to play with _cdec or _stdcall. Beside affecting on function name mangling, they dictate they way function parameters are stack/unstack. If you don't know what you are doing, do not play with them, and do not change the calling convention on the lib file, otherwise you'll get a crash at the first function call.

To change name mangling under windows, use *def file.

http://msdn.microsoft.com/en-us/library/d91k01sh(v=vs.80).aspx

Bruno

"Val Schmidt" wrote in message <jn6vev$o52$1@newscl01ah.mathworks.com>...
> Hello,
>
> I'm trying to compile a mex function that links to an external library. It is failing, being unable to find the "symbols" to the library function calls. I've spent an embarrassing amount of time trying to figure this out and any help would be greatly appreciated. Here's what I've got:
> ----------
> >> mex('gsf_Read.c','.\gsf_0303\WinGSF\Debug\WinGSF_lib.lib')
> Creating library C:\Users\vschmidt\AppData\Local\Temp\mex_p5d3gD\templib.x and object C:\Users\vschmidt\AppData\Local\Temp\mex_p5d3gD\templib.exp
> gsf_Read.obj : error LNK2019: unresolved external symbol gsfClose referenced in function mexFunction
> gsf_Read.obj : error LNK2019: unresolved external symbol gsfRead referenced in function mexFunction
> gsf_Read.obj : error LNK2019: unresolved external symbol gsfOpen referenced in function mexFunction
> gsf_Read.mexw64 : fatal error LNK1120: 3 unresolved externals
>
> C:\PROGRA~1\MATLAB\R2011B\BIN\MEX.PL: Error: Link of 'gsf_Read.mexw64' failed.
>
> -----------------
>
> gsfOpen, gsfRead and gsfClose are the library function calls.
>
> I can the cygwin/linux utilty "nm" to dump the symbol table from the library. When I do I see that the function calls are defined with a leading underscore (e.g. _gsfRead). This may be the problem. I read that the leading underscore is a convention common to windows and found an option in the Visual Studio build configuration called "Calling Convention" which passes options _cdecl (/Gd) or _stdcall (/Gz) to the compiler, the former of which is *supposed* to omit the leading underscore. However if I select this (it was the default) the leading underscore remains and in any case I read elsewhere that the compiler and linker are supposed to be smart enough to associated _gsfRead with gsfRead.

I'm not sure I follow all this. If your compiler exported the names *without* underscores, and the library *does* have underscores, why did you try an option (the default) that doesn't use the underscore? From what you describe, it seems like this simple fix should work to force underscores on the front of your function names:

#define gsfClose _gsfClose
#define gsfRead _gsfRead
#define gsfOpen _gsfOpen

James Tursa

> I don't think it's safe to play with _cdec or _stdcall. Beside affecting on function name mangling, they dictate they way function parameters are stack/unstack. If you don't know what you are doing, do not play with them, and do not change the calling convention on the lib file, otherwise you'll get a crash at the first function call.
>
> To change name mangling under windows, use *def file.
>
> http://msdn.microsoft.com/en-us/library/d91k01sh(v=vs.80).aspx
>
> Bruno

Ok. Thanks for the warning.