I maintain an old project and encountered some linker errors.
The error message is:
error LNK2019: unresolved external symbol __imp__bsearch referenced in function "bool __cdecl is_sync_host
As far as I know, the bsearch function is included in the header file "cstdlib" or "stdlib.h", but even if I include the header, I can't find "bsearch".
I suspect this is due to the fact that this old project ignores some lib because of symbol conflicts (I also don't know why they prefer to omit the lib instead of renaming the functions)
The ignored libs : msvcrt.lib;msvcrtd.lib;libcmt.lib;libc.lib
I try to add those ignored libs back, but then I encounter a lot of "symbol redefinition" problems and I don't think that renaming those functions is an applicable solution.
I found a work around (replace the bsearch to std::binary_search), but I want to know why and how to solve this problem properly (how comes the compiler can't find the bsearch?). Thanks.
error LNK2019:
This is a linker error. Your code compiled just fine (.c > .o), it is the linking that gives you problems (.o > .exe).
The ignored libs : "msvcrt.lib;msvcrtd.lib;libcmt.lib;libc.lib"
This means the code is ignoring the C standard library, so no wonder it doesn't find the standard bsearch() function...
The question is, why? There is simply no reason (that I could think of) for well-written code to explicitly ignore the standard library.
I try to add those ignored libs back, but then I meet a lot of "symbol redefinition" problems...
Which brings me to the conclusion that your code is not "well-written", at which point it is very difficult to give advice without seeing the code, or telling you to "ditch it, it's crap". ;-)
I don't think that rename those functions is an applicable solution.
If you have functions in your project that are named like standard library functions, unless your project is a standard library, they are misnamed and should be renamed.
But at this point, I would really like to see the code in question to figure out what the original programmer might have had in mind...
Related
I'm trying to compile a src code of an application that have the libs stripped from the files.
I already downloaded, compiled and linked each lib the project needs but I'm having trouble with a specific one: crypto (https://www.cryptopp.com/).
I receive a LNK2005 (symbol already defined) when trying to compile. The exact error message is:
Error LNK2005 "public: __cdecl CryptoPP::Rijndael::Enc::Enc(void)"
(??0Enc#Rijndael#CryptoPP##QEAA#XZ) already defined in
cryptlib_5_65-v141-x64.lib(rijndael.obj) IGC.GameServer D:\MU
Online\IGCN_S9E2_Emu\source\GameServer\PacketEncrypt.obj 1
Error LNK1169 one or more multiply defined symbols
found IGC.GameServer D:\MU
Online\IGCN_S9E2_Emu\source\Output\IGC.GameServer\Release\IGC.GameServer.exe 1
Apparently the linker is complaining that the type public: __cdecl CryptoPP::Rijndael::Enc::Enc(void) is being defined twice (in rijndael.obj - crypto lib - and in PacketEncrypt.obj - the project I'm trying to compile).
I already had fixed the LNK2005 a lot of times in the past but this time I just can't figure out what's hapening.
As I don't know what can be causing this error I don't know exactly what to share here regarding the code. Bellow is some code I think that can help but if you feel something is missing you can ask for more code.
Declaration of the type being defined twice
Problematic declaration
If I comment the two lines selected in the second print (and obviously cut off their references in the code) I can compile the project without any problem.
Thanks in advance.
So you are linking cryptlib_5_65 to IGC.GameServer, but the cryptlib already have that function. I am guessing that rijndael.cpp actually belongs to cryptlib project, but you added the source file to GameServer project as well. Check if that file is not in both projects and if so, remove it from the GameServer.
Implementation should be only in one of them.
It might not be the case, but the lack of better info from you, makes it difficult to find solution.
I would post it as a comment, but not enough points on my side.
I've got an NIUSB8452 DAQ, with which the vendor thoughtfully provided ni845x.lib and ni845x.h so I could use C instead of LabView to do my data reading. However, I'm having some problems with getting the lib working in VisualStudio 2015. The first point of alarm is probably that their documentation says it is compatible with VS6, but I've seen other people on here successfully use libraries for VS6 on VS15, so, I hope I can also be so beautiful.
The problem that I am having right now is that on a build, I'm getting linker errors that read something like
unresolved external symbol #ni845xStatusToString#12 referenced in function (function name follows)
While googling around, I found this question which mentioned dumpbin /exports. To check that I wasn't running into a 32/64 bit error like the poster described (since I wasn't really sure how to diagnose this, it seemed as good a place to start as any), I ran dumpbin /exports on the external lib. I got a pile of public symbols, including
FF06 __imp__ni845xStatusToString#12
FF06 _ni845xStatusToString#12
I'm definitely not seeing #ni845xStatusToString#12, which is what VisualStudio is complaining about being unresolved.
What's the difference between #ni845xStatusToString#12 and _ni845xStatusToString12? What does the presence of the latter and the absence of the former indicate that I am doing wrong with this import?
Notes
The lib and header have been included in the file as described in this question, with the exception that I gave a full path to the lib for #4, which I think implies you only need the filename.
I'm using extern "C" { #include ni845x.h } in my cpp file, although ni845x.h does have the #ifdef __cplusplus boilerplate in there.
Getting many versions of the following linker error in XE5.
[ilink32 Error] Error: Unresolved external '__stdcall System::UnicodeString::~UnicodeString()' referenced from <Location>
From everything I've read so far, this seems like I have something wrong with my include structure in the project settings and have no access to where all the string methods are actually defined, but for the life of me, I cannot figure out where these are supposed to be.
This problem has nothing to do with includes. Include problems only affect the compiler. Your project is using the UnicodeString class, so the compiler generates references to UnicodeString's methods based on how they are declared in ustring.h, and that keeps the compiler happy.
You are getting a linker error instead, because it cannot resolve the references that the compiler generated. That means your project is missing a required reference to Embarcadero's RTL library that implements the actual UnicodeString method bodies. That likely suggests your project was created/imported incorrectly to begin with, or has become corrupted. You may have to recreate the project from scratch so the default library references are used, and re-add your existing code files to that new project.
I am receiving a lot of strange LNK2001 and LNK2019 errors when attempting to compile and link against a somewhat large static library (developed in-house). Here are the facts:
There are several static libs (most built in-house) all compiled into one large wrapper static lib for public consumption ("Pimpl" idiom). Essentially, we have libs A, B, and C all compiled into an internal/private lib called D. Then, we have an external/public lib that wraps around D called E.
The final product is not an executable, but a plug-in for Adobe Illustrator. Plug-ins are essentially just a DLL with a couple special resources and a special entry point (PluginMain() function). Compiling and linking works just great until I use the /INCLUDE option to specify that PluginMain should always be exported.
Creating a plug-in and linking against lib D works fine (no errors whatsoever). Creating a plug-in and linking against lib E gives over 100 unresolved symbol errors (symbols that should be present in E).
When I run DUMPBIN on the E.lib file, it appears to have all the symbols that the linker is complaining about when trying to create a plug-in. However, I'm not entirely certain I understand all the output syntax from DUMPBIN...
The libs are all cross-platform and compile and link just fine with GCC/LLVM on Mac.
Most of the functions that the linker complains about are either plain functions or static member functions. Most of those look suspiciously like functions that the compiler might try to inline. I have tried disabling optimization and/or automatic inlining, but the same link errors are still present.
Can anyone point me in the direction of some compile and/or link settings that might resolve the issue? Settings that are commonly misconfigured in situations like this?
Perhaps there is a setting I missed that is causing the linker not to export these symbols when linking E? Perhaps there is a setting that forces the linker to export ALL symbols when linking E that I can try? Maybe a utility exists to help me inspect the lib symbols myself for a clue?
I feel like I've tried everything, but it never hurts to ask. Thanks all.
EDIT 1: snowdude requested an actual link error:
E.lib(PathArt.cpp.obj) : error LNK2001: unresolved external symbol "private: __thiscall E::PathSegPoint::PathSegPoint(struct D::PathSegPoint const &)" (??0PathSegPoint#E##AAE#ABU0D###Z)
I should add that E::PathSegPoint::PathSegPoint(const D::PathSegPoint&) is a private constructor for constructing an external/public consumable E::PathSegPoint object from an internal/private D::PathSegPoint object. Again, this is the "Pimpl" idiom. Some classes/functions are friends of E::PathSegPoint to enable this sort of construction.
I thought I'd post an answer in case anyone shows up to this page in the future.
For several reasons a few years ago, we started compiling these libraries with the Intel C++ compiler inside Visual Studio. Some of these reasons have changed, and we needed to switch back to the MSVC compiler. Upon switching to the MSVC compiler, these linker errors disappeared!
I don't know why or how the Intel C++ compiler developed these link problems, but it's entirely possible that this is a bug.
I've opened an old workspace that is a libray and its test harness. It used to work fine but now doesn't and older versions of the code don't work either with the same errors. I've tried recreating the project and that causes the same errors too. Nothing seems out of order in project settings and the code generated works in the main app.
I've stripped out most of the files and got it down to the bare minimum to generate the error. Unfortunately I can't post the project as this is used in production code.
The LNK2001 linker error I get usually means I've left off a library or forgot to implement a virtual function. However this is part of the standard template library - and is a header at that.
The code that is listed as having the problem in IOCompletionPort.obj doesn't actually use std::string directly, but does call a class that does: Comms::Exception accepts a std::string and the value of GetLastError or WSAGetLastError.
The function mentioned in the error (GetMessage) is implemented, but is a virtual function so other classes can override it if need be. However it appears that the compiler has made it as an Ansi version, but I can't find any options in the settings that would control that. I suspect that might be the problem but since there's very little in the way of options for the library I have no way of knowing for sure. However both projects to specify _MBCS in the compiler options.
--------------------Configuration: TestComms - Win32 Debug-------------------- Linking... Comms.lib(IOCompletionPort.obj)
: error LNK2001: unresolved external symbol "public: virtual class
std::basic_string,class
std::allocator > __thiscall
Comms::Exception::GetMessageA(void)const " (?GetMessageA#
Exception#Comms##UBE?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##XZ)
Debug/TestComms.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
TestComms.exe - 2 error(s), 0 warning(s)
Any suggestions? I've lost most of the morning to this and don't want to lose most of the afternoon too.
One possibility lies with Win32 ANSI/Unicode "name-mangling", which turns the symbol GetMessage into either GetMessageA or GetMessageW. There are three possibilities:
Windows.h hasn't been loaded, so GetMessage stays GetMessage
Windows.h was loaded with symbols set for ANSI, so GetMessage becomes GetMessageA
Windows.h was loaded with symbols set for Unicode, so GetMessage becomes GetMessageW
If you've compiled two different files in ways that trigger two different scenarios, you'll get a linker error. The error message indicates that the Comms::Exception class was an instance of #2, above -- perhaps it's used somewhere that windows.h hasn't been loaded?
Other things I'd do in your place, just as a matter of routine:
1) Ensure that my include and library paths don't contain anything that I'm not expecting.
2) Do a "build clean" and then manually verify it, deleting any extra object files if necessary.
3) Make sure there aren't any hardcoded paths in include statements that don't mean what they meant when the project was originally rebuilt.
EDIT: Fighting with the formatting :(
#Curt: I think you came the closest. I haven't tested this but I think I sort of gave the answer in my original question.
GetMessage is a define in Windows.h wrapped in a ifndef block to switch between Ansi (GetMessageA) and Unicode (GetMessageW).
Presuming you haven't futzed around with the Project settings deleting something you ought not have (which is where I'd expect external dependencies like User32.lib to be):
Check Tools | Options | Directories | Libraries (going from memory here) and ensure that you're not missing the common-all-garden variety lib directories (again, without VC6 in front of me, I can't tell you what they are)
This is a general problem with the way Microsoft handled the ANSI vs. Unicode APIs. Since they are all (or pretty much all) done by defining macros for the function names that resolve to the 'A' or 'W' versions of the function names you cannot safely have an identifier in your namespace/class/struct/enum/function that matches a Windows API name.
The windows.h macros run roughshod over all other namespaces.
windows.h is declared at the top of IOCompletionPort.h as an include - I was sick of seeing 7 lines just to include 1 file so I have wrapped it its own file and includes that itself. This also contains some additional #defines (i.e. ULONG_PTR) as our main app won't compile with the Platform SDK installed:-(
That is confirmed. Nothing is out of place.
I've done that - deleted the build directories
I never use hard-coded paths.