Unresolved external symbol: @12 vs @8 at the end of symbol name

Question

Hi all,

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.