Linking problem - unresolved external symbol

Hello, can't make link, get this error message:

dcpp.lib(HashManager.obj) : error LNK2001: unresolved external symbol unwind.?fastHash@Hasher@HashManager@dcpp@@QEAA_NAEBV?$basic_string@DV?$char_traits@D@stlpx_std@@V?$allocator@D@2@@stlpx_std@@PEAEAEAV?$MerkleTree@VTigerHash@dcpp@@$0EAA@@3@_JPEAVCRC32Filter@3@@Z.0.11

But symbol unwind.?fastHash@Hasher@HashManager@dcpp@@QEAA_NAEBV?$basic_string@DV?$char_traits@D@stlpx_std@@V?$allocator@D@2@@stlpx_std@@PEAEAEAV?$MerkleTree@VTigerHash@dcpp@@$0EAA@@3@_JPEAVCRC32Filter@3@@Z.0.11 is contained inside dcpp.lib, I don't understand what the error message mean, any explanation?

Quote:

---

Originally Posted by Anakunda

Hello, can't make link, get this error message:

dcpp.lib(HashManager.obj) : error LNK2001: unresolved external symbol unwind.?fastHash@Hasher@HashManager@dcpp@@QEAA_NAEBV?$basic_string@DV?$char_traits@D@stlpx_std@@V?$allocator@D@2@@stlpx_std@@PEAEAEAV?$MerkleTree@VTigerHash@dcpp@@$0EAA@@3@_JPEAVCRC32Filter@3@@Z.0.11

But symbol unwind.?fastHash@Hasher@HashManager@dcpp@@QEAA_NAEBV?$basic_string@DV?$char_traits@D@stlpx_std@@V?$allocator@D@2@@stlpx_std@@PEAEAEAV?$MerkleTree@VTigerHash@dcpp@@$0EAA@@3@_JPEAVCRC32Filter@3@@Z.0.11 is contained inside dcpp.lib, I don't understand what the error message mean, any explanation?

---

The error message means what it says. What it means is that you failed to do something to make the linker find the library.

That could be anything -- you didn't include the correct library in your project, or the library doesn't have what you think it has, etc. The only way we could answer your question with certainty is to have your project and build it ourselves.

Regards,

Paul McKenzie

You 're right. That's because of missing name. But why is the symol missing.
Having the missing symbol demangle it is 11th unwind chunk of an own function.
Now I need to find out, why didnot compiler generate this chunk, while chunks 0.1 - 0.10 were generated?
Or did linker fail to locate it in generated code?
I'd need an hint to instruct compiler and generate all chunks properly, maybe command line switch, or pragma. I'm using /GX switch already.

Most likely you've declared something but forgot to implement it. Comment your latest code changes bit by bit until it compiles and links and take it from there.

Is the dcpp lib your own library or a third party library? If it is your own, it looks like as if a global or static variable wasn't defined (but only declared). If it is a foreign library you actually need to follow SMA's advice and find the statement that causes the missing symbol by commenting all statements where you were using the HashManager until it links properly. Then, post the code with the statement(s) that leads to the link error.

Quote:

---

Originally Posted by itsmeandnobodyelse

Is the dcpp lib your own library or a third party library?

---

As I wrote in post#3 deducing from the demangled symbol name it is own function (found it in own code), furthermore an unwind chunk of it, because unwind code is fully in arrangement of compiler I guess compiler failed to generate all unwind chunks as a new unwind chunk is generated for every scope change during the particular function.

I have found that this error only happend if compiling the x64 version of the project using 64bit compiler. Link is successfull in x86 target of same library.
Weird.
Possibly compiler bug?

Is this the code you trying to build? http://code.google.com/p/eiskaltdc/s...le/dcpp/?r=769
There are some #ifdef _WIN32 in the code. I have not built anything for 64 bits but I would expect when doing so _WIN64 is defined i.e. you probably try to build a non-windows version.

Looks like a clone but basically, yes.
Not to concern on the code self, I've gotten same error just awhile ago trying to build pcrecpp library (C++ frontend for libpcre).
Just curious. This error only happens with C++ code (C++ unwind), and always missing 2 unwind chunks of one own function.

It might be something that really should be separately treated for the Windows 64 bits builds. As I understand it gcc and MS use different size for an int when it comes to 64 bits applications. gcc use 64 bits and MS 32 bits but both use 64 bits pointers (can't find the link at the moment)

Edit: Found at least this one http://msdn.microsoft.com/en-us/libr...k5(VS.80).aspx

I don't use gcc, but ICL

Ok, so you define _WIN32 and build for 64 bits? I would guess that's asking for trouble

Quote:

---

Originally Posted by S_M_A

Ok, so you define _WIN32 and build for 64 bits? I would guess that's asking for trouble

---

The only thing that should be required should be WIN64 for 64-bit builds. Specifying WIN32 or _WIN32 for a 64-bit app will either produce a faulty build, or the compile will fail.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

The only thing that should be required should be WIN64 for 64-bit builds. Specifying WIN32 or _WIN32 for a 64-bit app will either produce a faulty build, or the compile will fail.

Regards,

Paul McKenzie

---

_WIN64 and WIN64 are defined as well as WIN32, _WIN32
Should I really undefine WIN32 & _WIN32 for that target ?
I've seen somewhere both *WIN64 and *WIN32 must be defined for 64bit targets, not sure though.

Yes either WIN32 or WIN64 should be defined. The code I found only had WIN32, that's why I suspected it to be the source for your issues.

Hmm I'm not sure about it.
Found a link to MSDN page about defines
http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx
saying _WIN32 Defined for applications for Win32 and Win64. Always defined.

Quote:

---

Originally Posted by Anakunda

Hmm I'm not sure about it.
Found a link to MSDN page about defines
http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx
saying _WIN32 Defined for applications for Win32 and Win64. Always defined.

---

What about the WIN32 preprocessor symbol, without the leading underscore? Same thing with WIN64. Many third-party headers use the non-underscore version (or some variation of them) to distinguish between a 32-bit build and 64-bit builds.

This is where you need to specify the correct preprocessor that the library code uses to distinguish between the two versions. My inclination is to just define WIN64 (or whatever preprocessor the library uses to define a 64-bit build) and let it be, since that has worked for me whenever I build a 64-bit app.

Regards,

Paul McKenzie