Linking to tcl85.lib with SWIG via MSVS (autogenerated by CMake)

Question

http://community.activestate.com/node/7011

It's kinda like that poor chap shang (can I use chap gender-neutrally?) over there in the link, except it's another year and I have MSVS 2012.

Details

CMake has placed C:...\Tcl\lib\tcl85.lib on the dependencies list for my binary (I checked in the generated .vcproj file - it's there). Nevertheless, the linker errors are numerous and of the form:

nativeTCL_wrap.obj : error LNK2019: unresolved external symbol __imp__Tcl_[some-command-name] referenced in function _SWIG_Tcl_[some-other-command-name].

So I check the header file as listed in the dependencies list for my project in MSVS: version is #define as 8.5. This matches the library that I'm trying to link to. I tried exploring tcl85.lib with dependency walker. Apparently it can't explore that kind of file. I ran dumpbin.exe on it... And the .lib file has ALL OF THE MISSING FUNCTIONS, but of the following form:

__imp_Tcl_[some-command-name]

It has all of the symbols... But there's an underscore missing in each of them!

I then explored the libtcl85.dll.a file given by ActiveState's Tcl distro used in Cygwin, and the symbols look like this:

__imp__Tcl_[some-command-name]

So it has the extra underscore, and the binary links properly on Cygwin.

...

This is seriously one of those moments where I'm throwing my hands up in the air and thinking, "What do?" in all of its simplistic grammatically screwed up glory. The same swig interface file with the same CMake generates a module successfully in Cygwin. But developing Cygwin is a pain in the ass because of how slow it is (builds are almost 5-8 times as long as in more native-Windows-ish systems).

What Happens Next?

Do I try to convince Swig to generate with dependencies with one less underscore? If so how? Do I give up and file a bug report? If so, where? Is this a bug in ActiveState Tcl? Is this a bug in Swig? Is this not a bug at all and I'm just screwed?

For the lack of an underscore the kingdom was lost?

Answer 1

So, as I was writing my question, I started thinking about all of the different alternatives to how this could have gone wrong. Then I remembered that CMake by default chooses the 32-bit version of MSVS. I am now feeling quite sheepish, but as someone else apparently had a similar problem on the ActiveState fora, I'm leaving my answer here for anyone else needing this little, tiny, itsy bitsy reminder...

As it turned out, selecting the 64-bit version of MSVS with cmake -G "Visual Studio 2012 Win64" fixed everything. Linking worked fine. The binary got loaded successfully into Tclsh.

I would've expected a more comprehensive error message from my build tool about trying to link 32-bit and 64-bit binaries together, though...