-
December 12th, 2010, 02:30 PM
#1
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?
-
December 12th, 2010, 04:29 PM
#2
Re: Linking problem - unresolved external symbol
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
-
December 13th, 2010, 08:04 AM
#3
Re: Linking problem - unresolved external symbol
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.
-
December 13th, 2010, 04:15 PM
#4
Re: Linking problem - unresolved external symbol
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.
-
December 14th, 2010, 05:52 AM
#5
Re: Linking problem - unresolved external symbol
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.
-
December 14th, 2010, 05:58 AM
#6
Re: Linking problem - unresolved external symbol
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.
-
December 14th, 2010, 03:29 PM
#7
Re: Linking problem - unresolved external symbol
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?
-
December 14th, 2010, 04:05 PM
#8
Re: Linking problem - unresolved external symbol
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.
Last edited by S_M_A; December 14th, 2010 at 04:08 PM.
-
December 14th, 2010, 04:12 PM
#9
Re: Linking problem - unresolved external symbol
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.
-
December 14th, 2010, 04:21 PM
#10
Re: Linking problem - unresolved external symbol
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
Last edited by S_M_A; December 14th, 2010 at 04:27 PM.
-
December 14th, 2010, 04:26 PM
#11
Re: Linking problem - unresolved external symbol
-
December 14th, 2010, 04:30 PM
#12
Re: Linking problem - unresolved external symbol
Ok, so you define _WIN32 and build for 64 bits? I would guess that's asking for trouble
-
December 14th, 2010, 05:22 PM
#13
Re: Linking problem - unresolved external symbol
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
-
December 14th, 2010, 05:34 PM
#14
Re: Linking problem - unresolved external symbol
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.
-
December 14th, 2010, 05:47 PM
#15
Re: Linking problem - unresolved external symbol
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|