I'm trying to compile my game with Visual Studio 2013. The game uses Box2D, but when compiling in Release mode the release Box2D.lib is giving errors. It works fine when compiling in Debug mode with the debug Box2D.lib.
I'm getting 135 errors, and mainly something like these three:
1>Box2D.lib(b2CollideEdge.obj) : error LNK2001: unresolved external symbol #__security_check_cookie#4
1>MyContactListener.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) char const * __cdecl std::_Winerror_map(int)"
(__imp_?_Winerror_map#std##YAPBDH#Z)
1>Box2D.lib(b2ContactManager.obj) : error LNK2001: unresolved external symbol _atexit
I have built the Box2D.lib's several times now, and I'm sure I'm linking to the right release and debug libraries.
I tried disabling the compiler flag /GS (Buffer Security Check), but that didn't help.
For building the Box2D.lib and when compiling the game I use the flag Multi-threaded DLL (/MD) for runtime library.
EDIT: I got rid of the errors "#__security_check_cookie#4" when I linked with the library "bufferoverflowU.lib". Still, 133 errors remain.
You probably disabled linking of default run-time libraries in linker options. Right-click on the project and go to properties. Under Linker->Input set an option Ignore All Default Libraries to No.
Related
While building my project, I get the same issue, solved in this links:
SOIL not linking correctly,
SOIL set-up in Visual Studio 2010
I tried every suggested solution:
build the VC8 and VC9 libraries to get the SOIL.lib (I'm using VS 2013)
linked the libraries (Linker - Additional Dependencies)
renamed the libSoil.a to SOIL.lib
but still having the same errors:
1>libSOIL.a(stb_image_aug.o) : error LNK2019: unresolved external symbol __alloca referenced in function _stbi_zlib_decode_noheader_buffer
1>libSOIL.a(image_helper.o) : error LNK2019: unresolved external symbol _sqrtf referenced in function _RGBE_to_RGBdivA2
Any ideas , other solutions?
We have a project which is an executable, which loads DLL files at run time as plugins.
We're trying to make a new plug in which has many library dependencies, and some of those dependencies are the same library but different versions that other plugins link to.
Because the libraries are depended on by different plugins at different versions, I would like to statically link/build any dependencies into the new plugin - that way they can't conflict with the old plugin dependencies. As far as I know, nothing in the dependencies of the plugin need to be exported, they're just used by the plugin.
Is it possible to do this?
I've tried building all the static libs in visual studio as static libraries with the runtime set to Multithreaded DLL with the /MD flag, but when I try to build dynamiclibB.dll, I get linker errors. If I set dynamiclibB to build as a static library, it doesn't have the linker errors.
I haven't tried linking newplugin.dll to the static library version of dynamiclibB yet, but I think I have exactly the same situation, so I see no reason why it would work there where it doesn't one level down.
I don't want to build dynamiclibB as a static library anyway, as it would be good to be able to update newplugin.dll without including dynamiclibB.dll if it hasn't been changed, as in, to decouple the update process. This line of reasoning would suggest that I should have .dlls for everything, but the conflicts of versions is what worries me, I think.
I cannot build the plugins as static libraries as they need to be loaded at run time.
Absolutely everything is being built in release mode for now, to avoid that complication.
What am I missing?
An attempt at a diagram that might help understand the situation:
program.exe
|
________________
| |
oldplugin.dll newplugin.dll
| |
dynamiclibA.dll dynamiclibB.dll
|
_________________________
| | |
staticlibA.lib slibC.lib slibD.lib
Update:
Providing some more information now that I know what's happening, and know that more specific details are actually relevant.
So library A, represented by dynamiclibA and staticlibA was zlib.
The library we were compiling (dynamiclibB) for use in the newplugin was PoDoFo.
The error messages we got were:
Error 19 error LNK2001: unresolved external symbol
_deflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 20 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 21 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngread.obj) podofo_shared Error 22 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 23 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\libpng16.lib(pngwutil.obj) podofo_shared Error 24 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 25 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngwrite.obj) podofo_shared Error 26 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 27 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared Error 28 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 29 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared
Putting the rest in an answer.
In my question, slibc.lib was libpng. Libpng also requires zlib, but it builds it from source inside its solution. We were able to use the output of that project in the way we desired, as in, zlib.lib built with /MD flag, without linking errors.
We've also managed to work out why this problem occurred:
another stackoverflow question was very relevant: https://stackoverflow.com/a/6559315/78823
Turns out that zlib has a #define ZLIB_WINAPI which defined the call convention to be STDCALL, which I don't understand, but it caused the linker errors. The other answer suggests to remove the define, and I suppose that's what libpng did with its zlib project.
I'm guessing that the reason why the linker errors only occurred when building the .dll and disappeared when building the .lib is because (correct me if I'm wrong, I don't fully understand this), build a .lib doesn't actually do the linking to the required functions, so would have been just passing on the linker errors to the next level up; I think we would have seen the same errors (but in different objs/projects perhaps) when compiling newplugin.dll, but we didn't get far enough to check that before we tried other things.
I have recently migrated a project from x32 to x64 in VS professional 2008 and I'm getting this weird linker errors:
error LNK2001: unresolved external symbol __imp_PostMessageW
error LNK2001: unresolved external symbol __imp_FlushFileBuffers
error LNK2001: unresolved external symbol __imp_WriteFile
error LNK2001: unresolved external symbol __imp_WaitForSingleObject
error LNK2001: unresolved external symbol __imp_SetFilePointer
error LNK2001: unresolved external symbol __imp_EnterCriticalSection
...
And more of this nature.
I am including shlwapi.lib in the linker.
Running on Windows 7 x64.
Additional Dependencies:
The solution for my problem was setting Linker > General > Additional Library Directories with "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\x64" instead of "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib".
Ensure that the x64 configuration is selected. Right-click your project in the Solution Explorer window, Properties, Linker, Input. Click on the Additional Dependencies box and click the button that appears.
This is what it should look like if the project is configured correctly. Note how the "Inherit" checkbox is ticked and how the inherited values list the standard SDK libraries. Like kernel32.lib, the link library that has the definition for __imp_FlushFileBuffers, etc. If it doesn't look like this in your project then you'll get these linker errors.
I'm trying to use the WMI example from msdn:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384724%28v=vs.85%29.aspx
I've copied the last set of code there verbatim into a console application in VS2008. If I have the application in release or debug for the win32 platform, it compiles (and runs) fine. If I have it in release or debug for the x64 platform, I get the following linker errors:
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemConfigureRefresher
CppConsole.obj : error LNK2001: unresolved external symbol CLSID_WbemRefresher
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemRefresher
CppConsole.obj : error LNK2001: unresolved external symbol CLSID_WbemLocator
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemLocator
fatal error LNK1120: 5 unresolved externals
I've already tried putting the wbemuuid.lib into the linker input directly in the project properties, but that didn't make a difference from the pragma.
Has anybody made this work with x64? Or is there something else I'm doing wrong?
I give credit to RRUZ for this, as he/she at least put me on the right track, but as they haven't posted an answer-answer (just a comment) I can't click them for credit.
Basically, because of the work environment I'm in, the project directories are set up in a "non-standard" way. There was already a copy of wbemuuid.lib in another directory that was not the correct version (not x64), and that directory was higher on the library include list, thus never getting to the right Windows Platform library directory.
So if you ever have problems with x86 vs x64 and library includes, check your directories and check the ORDER of them as well.
Link errors like this sometimes occur when compiling C++ using Microsoft Visual C++ 6.0:
error LNK2001: unresolved external symbol __imp__close
error LNK2001: unresolved external symbol __imp__read
error LNK2001: unresolved external symbol __imp__lseek
error LNK2001: unresolved external symbol __imp__open
My fix, which I found after searching fruitlessly using Google for a long time, is this:
Do NOT disable language extensions. In the Project Settings dialog, in the C/C++ tab, make sure that the 'Disable language extensions' checkbox is not checked.
The functions close, read, lseek, open, etc., are not standard parts of the C library and the declarations are skipped by conditional compilation using #if !__STDC__ in <io.h>. This happens if you disable language extensions.
The answer is that the __imp prefix refers to function stubs in the OBJ library for the DLL version of the CRT. This means your linker options are incompatible with your compiler options (linker set to static CRT or no CRT and compiler set to dynamic CRT).
In your case rather than the CRT itself it is another library, but the same idea.