Example/matlab/simple causing LNK2019 Error on MSVC2010

[zchen24]

Default interface file example_wrap.cxx is cpp format. This means the compiler is expecting manged function name (i.e. "int __cdecl gcd(int,int)" instead of "int gcd(int,int)"). The default version triggers a LNK2019 error using MSVC2010. This can be fixed by adding extern "C" into example.i file.

BTW, is there a reason that the default output file format is cpp format? Thanks!

[jaeandersson]

On vacation now, will have a look at this when I get home.

[zchen24]

Just want to check if this issue has been confirmed?

[jaeandersson]

I don't have MSVC2010 here, but googling a bit suggests the following fix that I committed to a separate branch 726bac79575356358623a7532faca2cf1ce0a0e5. You need need to pull branch issue_35 from me.

Does this resolve the issue?

[jaeandersson]

BTW, is there a reason that the default output file format is cpp format? Thanks!

Is it? If so, it's probably a leftover from Octave (the MATLAB is based on the Octave module but uses Octave's C++ API, which is very different from MATLAB's MEX API).

[zchen24]

I think so. I have swig compiled using cygwin. After calling swig by swig -matlab example.i, I get exasmple_wrap.cxx file. Not sure if it's the same case under Linux or OS X.

[zchen24]

Thanks for the commit. I think the commit you provided is for Windows DLL export. The issue really is calling C functions from C++ file. As the default output file has cxx extension, mex uses C++ compiler and linker for example_wrap.cxx, but uses C compiler for example.c.

The fix is in the example.i add "C", or just simply change example.c file extension to cpp .....

%inline %{
extern "C" int    gcd(int x, int y);
extern "C" double Foo;
%}

[jaeandersson]

I'm not sure if I understand. Did you try enabling the c++ mode?

swig -c++ -matlab example.i

Also try to change the ending to C, since the code (without the c++ flag) should be valid C:

swig -matlab -o example.c example.i

Maybe the suffix detemines whether MSVC will use the C or C++ mode.

[zchen24]

No I did NOT pass -c++ option.

Maybe the suffix detemines whether MSVC will use the C or C++ mode.

I don't agree. SWIG does not know which compiler will be used at time of generating code.

[jaeandersson]

I'm a bit lost here. So, either you compile the wrapper with a C compiler (it should be valid C code) and then extern "C" is of course not needed. If you want the wrapper to be C++, but wrapping a C library (makes sense if you want to use the "%extend" feature in SWIG) then you indeed need to specify extern "C". Or you "%include" C header files with C++ guards:

#ifdef __cplusplus
extern "C" {
#endif

int  gcd(int x, int y);
double Foo;

#ifdef __cplusplus
}
#endif

[jaeandersson]

My guess is that because of the .cpp suffix, MSVC went into C++ mode, but since you hadn't specified extern "C" linkage, you get a linking error. If you change the suffix to .c, MSVC will probably run in C mode and then there is no linking problem.

[zchen24]

That's exactly what the issue is. I think the proper fix is to have the C++ guard setup correctly. Then it does NOT matter what the default output suffix is.

[jaeandersson]

Yes, you're probably right about the C++ guards. Feel free to make a pull request if you find a solution.

[zchen24]

Will do.