未解析的外部符号：符号名称末尾的 @12 与 @8
我对 C++ 没有任何重要的经验，但最近不得不参与 C++ 部分的项目（实际上是 apache 模块）。
现在，我只是试图构建一些现有的非常遗留的代码，并且当 VC++ 链接器无法在 apache 库中找到一个特定函数（同时看到其余的函数）时，我会遇到非常奇怪的问题。
代码如下（取自专门为解决此问题而构建的简单示例）：
ap_rputs(ap_gm_timestr_822(r->pool, time(NULL)), r);
（这应该只是打印当前日期，但这并不重要）
我得到的错误是这样的：
error LNK2019: unresolved external symbol _ap_gm_timestr_822@12 referenced in function _hello_handler
现在到奇怪的部分：这个函数实际上存在于我链接的库中，但其符号名称是 _ap_gm_timestr_822@8 （不是 @12，而是 @8结尾）。
我尝试使用 MSVC++ 中几乎所有可能的编译器/链接器属性 - 不幸的是，没有效果。
这个问题是否与以下事实有关：该库（属于 apache 1.3 发行版的一部分）是使用与我使用的不同/旧/...编译器构建的？我目前正在使用 MS VC++ Express 2008。如果是这种情况，有人知道可以采取什么措施来解决这个问题吗？
I don't have any significant experience with C++ but recently had to be involved into the project with C++ part (apache modules, actually).
Right now I am just trying to build some existing very much legacy code and face the very weird problem when VC++ linker cannot find one particular function in the apache library (while seeing the rest of them).
The code is like this (as taken from the trivial sample built specifically to tackle this problem):
ap_rputs(ap_gm_timestr_822(r->pool, time(NULL)), r);
(this should just print current date, but it does not really matter much)
And the error I am getting is like this:
error LNK2019: unresolved external symbol _ap_gm_timestr_822@12 referenced in function _hello_handler
Now to the weird part: this function actually exists in the library I am linking with, but its symbol name there is _ap_gm_timestr_822@8 (not @12, but @8 at the end).
I tried to play with almost every possible compiler / linker property in MSVC++ - to no effect, unfortunately.
Could this problem be related to the fact that the library (which is part of apache 1.3 distribution) is built with a different / older / ... compiler than I am using? I am currently using MS VC++ Express 2008. If this is the case, does anyone has an idea of what can be done to get around this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
time_t typedef 有两种风格，传统的 32 位会产生 Y2K38 问题，而 64 位则是该问题的解决方案。你这里有一个不匹配的地方。
检查您使用的 CRT 的 time.h 头文件，其中应该有一个#ifdef，用于在旧版本和 64 位版本之间进行选择。如果您仍希望在 2038 年成为一名程序员，请避免使用旧版。
The time_t typedef comes in two flavors, legacy 32-bits that will create the Y2K38 problem and 64-bits, the solution to that problem. You've got a mismatch here.
Check the time.h header file of the CRT you use, there should be a #ifdef in it that selects between the legacy and the 64-bit version. Avoid using legacy if you still expect to be a programmer by 2038.
在 Visual Studio 中，@ 后缀表示参数的总字节大小。两个函数之间不同的事实意味着签名不匹配。考虑到大小差异，您很可能正在尝试从 64 位链接到 32 位函数。
In Visual Studio, the @ suffix indicates the total byte size of the arguments. The fact that it differs between the two functions means a signature mismatch. Most likely, given the size difference, you are attempting to link to 32bit function from 64bit.
这些组成名称是函数名称与参数类型详细信息的组合。
因此，您包含的头文件声明的函数的参数与您链接的库不匹配。
当编译器命令行上的“-define”错误时，我最常遇到此问题，因此在头文件中选择与要链接的库不匹配的选项。通常这是通过选择您想要的“线程”，或者如果您想要 Unicode。
因此请检查编译器命令行是否与链接器命令行正确匹配。
These make up names are the names of the function combined with details of the type of arguments.
So the header file you are including declared the function with arguments that don’t match the lib you are linking with.
I have hit this most often when a “-define” is wrong on the compiler command line, so choosing an option in the header file that does not match the lib you are linking with. Often this is with selecting the “threading” you want, or if you want Unicode.
So check if you compiler command line correctly matches you linker command line.