Visual studio 2012 通过MSV（由CMake自动生成）通过SWIG链接到tcl85.lib

这有点像链接中那个可怜的尚先生（我可以用中性的chap吗？），除了又是一年，我有MSVS2012

详细信息

CMake已将C:…\Tcl\lib\tcl85.lib放在我的二进制文件的依赖项列表中（我签入了生成的.vcproj文件，它就在那里）。然而，链接器错误很多，其形式如下：

nativeTCL_wrap.obj:错误LNK2019:函数_SWIG_Tcl_u[其他一些命令名]中引用的未解析外部符号uu imp_utcl_uu[some command name]

因此，我检查了MSVS中项目的依赖项列表中列出的头文件：版本为

#定义为8.5。这与我试图链接到的库相匹配。我尝试使用dependency walker探索tcl85.lib。显然，它无法探索这种文件。我在上面运行了dumpbin.exe。。。.lib文件具有所有缺少的函数，但形式如下：

__imp\u Tcl\usome命令名

它有所有的符号。。。但它们中的每一个都缺少下划线

然后，我研究了libtcl85.dll。这是ActiveState的Tcl发行版在Cygwin中提供的一个文件，符号如下所示：

__imp_uutcl_uu[一些命令名]

因此，它在Cygwin上有额外的下划线和正确的二进制链接


这是一个严肃的时刻，我把双手举在空中，想着“你做什么？”在所有简单的语法错误的荣耀中。具有相同CMake的相同swig接口文件在Cygwin中成功生成模块。但是开发Cygwin是一件麻烦事，因为它的速度太慢了（构建的时间几乎是原生Windows系统的5-8倍）

接下来会发生什么？

我是否试图说服Swig使用更少的下划线生成依赖项？如果是，怎么做？我应该放弃并提交错误报告吗？如果是，在哪里？这是ActiveState Tcl中的一个bug吗？这是Swig中的一个bug吗？难道这根本不是一个错误，而我就完蛋了

因为没有下划线，王国消失了？
所以，当我写我的问题时，我开始思考所有不同的替代方案，以避免出现错误。然后我记得CMake默认选择32位版本的MSV。我现在感到很不好意思，但由于其他人在ActiveState论坛上显然也有类似的问题，我将把我的答案留在这里，让其他需要这个小小的、有点小的提醒的人知道

事实证明，使用
cmake-G“Visual Studio 2012 Win64”选择64位版本的MSV修复了所有问题。链接工作得很好。二进制文件已成功加载到Tclsh中

我本以为我的构建工具会给出一条更全面的错误消息，关于试图将32位和64位二进制文件链接在一起，但是…
所以，在我写问题的时候，我开始考虑所有不同的替代方法，以避免出现错误。然后我记得CMake默认选择32位版本的MSV。我现在感到很不好意思，但由于其他人在ActiveState论坛上显然也有类似的问题，我将把我的答案留在这里，让其他需要这个小小的、有点小的提醒的人知道

事实证明，使用
cmake-G“Visual Studio 2012 Win64”选择64位版本的MSV修复了所有问题。链接工作得很好。二进制文件已成功加载到Tclsh中

我希望我的构建工具会给出一个更全面的错误消息，关于如何将32位和64位二进制文件链接在一起，尽管…
当您有多个体系结构时，许多工具会变得更加棘手。在很长一段时间里，这在Windows上不是一个典型的问题，所以关于这个主题的“社区智慧”相当低，但是现在你已经有了32位和64位的体系结构（都由编译器支持！），因此丑陋的细节被暴露了出来。（你不能在同一个二进制文件中混合使用32位和64位代码——它们之间的调用——而没有超出正常级别的技巧，我们当然不会为Tcl实现中的那种疯狂而烦恼……）我想你不知道下划线是否是一个广泛使用的细节？我能在其他二进制文件中看到它吗？你知道，所以我可能会更早地认识到这类事情，而不是输入一个巨大的详细的so问题，几分钟后才意识到这是一件非常愚蠢的事情。>_@DonalFellows仍在学习SO的工作原理-因此，请原谅不恰当的名称标记。我也不能编辑我的评论。。。实际的消息内容在前面的消息中。当您有多个架构时，许多工具会变得非常棘手。在很长一段时间里，这在Windows上不是一个典型的问题，所以关于这个主题的“社区智慧”相当低，但是现在你已经有了32位和64位的体系结构（都由编译器支持！），因此丑陋的细节被暴露了出来。（你不能在同一个二进制文件中混合使用32位和64位代码——它们之间的调用——而没有超出正常级别的技巧，我们当然不会为Tcl实现中的那种疯狂而烦恼……）我想你不知道下划线是否是一个广泛使用的细节？我能在其他二进制文件中看到它吗？你知道，所以我可能会更早地认识到这类事情，而不是输入一个巨大的详细的so问题，几分钟后才意识到这是一件非常愚蠢的事情。>_@DonalFellows仍在学习SO的工作原理-因此，请原谅不恰当的名称标记。我也不能编辑我的评论。。。实际消息内容在上一条消息中。