I am trying to compile a small 2D engine I am working on. So far this has gone well, but ever since I included GLEW (as I wanted to start working on some fragment shaders) the test program refuses to build. To clarify, I build the engine as a static library (Mage2D.lib), and then build a test program that uses the library.
This is the error I am getting:
1>Link:
1> libpng15.lib(pngget.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>Mage2D_D.lib(root.obj) : error LNK2001: unresolved external symbol __imp__glewIsSupported#4
1>Mage2D_D.lib(root.obj) : error LNK2001: unresolved external symbol __imp__glewInit#0
1>C:\Users\Jesse\Documents\Visual Studio 2010\Projects\Rose\Debug\MageTest.exe : fatal error LNK1120: 2 unresolved externals
1>
1>Build FAILED.
Now normally I realize this means I'm not including the right library into my test program (glew32.lib). But that's impossibly the case here, as I build glew.c into Mage2D.lib. GLEW is literally part of the source code of Mage2D as it seemed convenient to do that with a program that is four files and integral part of the engine anyway.
I followed GLEW's instructions on their website to the letter on how to build GLEW and include it into my project, but I keep getting this error.
What the hell is going on?
I've checked glew.h and I'm quite sure you need to add GLEW_STATIC define just before including glew.h:
#define GLEW_STATIC
#include "GL/glew.h"
Related
I was following the tutorial in LibTorch here.
With the following changes:
example-app => Ceres
example-app.cpp => main.cxx
Everything worked until the CMake command cmake --build . --config Release.
It produced the following errors:
main.obj : error LNK2001: unresolved external symbol __imp___tls_index_?init#?1??lazy_init_num_threads#internal#at##YAXXZ#4_NA [D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\build\Ceres.vcxproj]
main.obj : error LNK2001: unresolved external symbol __imp___tls_offset_?init#?1??lazy_init_num_threads#internal#at##YAXXZ#4_NA [D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\build\Ceres.vcxproj]
D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\build\Release\Ceres.exe : fatal error LNK1120: 2 unresolved externals [D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\build\Ceres.vcxproj]
I don't believe these are from the changes I placed, since the problem is with the linking.
I also am trying to replicate this directly into Visual Studio. I am using Visual Studio 17 2022 which the LibTorch extension is not yet compatible with (Visual Studio 16 2019 is no longer available for install from the website).
The replication is through a blank C++ template (no starting files). And I have set the following macros:
LibTorchTarget = CPU specifies libtorch for CPU is to be used (useful for other macros
LibTorchDir = C:/libtorch/ directory where the libtorch installation(s) can be found (for multiple installations)
LibTorchInstall = $(LibTorchDir)libtorch_$(LibTorchTarget)/ expresses to C:/libtorch/libtorch_CPU/
LibTorchInclude = $(LibTorchInstall)include/ expresses to C:/libtorch/libtorch_CPU/include/
LibTorchLib = $(LibTorchInstall)lib/ expresses to C:/libtorch/libtorch_CPU/lib/
And have put the Include and Lib macros at their respective VC++ Directories positions. As well as $(LibTorchLib)*.lib (C:/libtorch/libtorch_CPU/lib/*.lib) in the Linker > Input > Additional Dependencies to specify all the .libs for linking (prevents a lot of LNK2009 errors).
And lastly, I have put start xcopy /s "$(LibTorchLib)*.dll" "$(OutDir)" /Y /E /D /R command at the Build Events > Pre-Link Event > Command Line to replicate the if clause in the CMakeLists.txt in the tutorial (apparently to avoid memory errors).
Result is same exact error with a final LNK1120 error:
Error LNK2001 unresolved external symbol __imp___tls_index_?init#?1??lazy_init_num_threads#internal#at##YAXXZ#4_NA Ceres D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\main.obj 1
Error LNK2001 unresolved external symbol __imp___tls_offset_?init#?1??lazy_init_num_threads#internal#at##YAXXZ#4_NA Ceres D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\src\Ceres\main.obj 1
Error LNK1120 2 unresolved externals Ceres D:\Silverous Black\CPE42S2-CPE42S2\CPE 406\ProjectDumagan\out\Debug_64\Ceres\Ceres.exe 1
I don't exactly understand the reason for the LNK errors, so if anyone could help that'll be really nice. Thank you in advance.
Look to: Updating to Visual Studio 17.4.0 Yields linker errors related to TLS
You most likely need to rebuild PyTorch after MSVC update.
I have a makefile project in my system. Recently, I added some new functions which makes use of the following Windows APIs:
RegOpenKeyEx
RegEnumKeyEx
RegCloseKey
RegGetValue
For having those APIS I added the windows.h header file as well.
The code compiles and links fine in my machine. But, linking fails in my colleagues machine. We all are working on 64 bit windows machine.
In his PC I get the error:
error LNK2001: unresolved external symbol __imp_RegOpenKeyExW
error LNK2001: unresolved external symbol __imp_RegGetValueW
error LNK2001: unresolved external symbol __imp_RegCloseKey
error LNK2001: unresolved external symbol __imp_RegEnumKeyExW
What I tried:
Since the library being used was Advapi32.lib in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64
I tried adding following line:
LINKFLAGS += -L "C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Lib\x64"
I added the path of the library to environment variable PATH
I copied the lib to the output folder.
Nothing worked.
As I said earlier, the code works fine in my PC but fails in another one.
The registry functions require you to pass Advapi32.lib to the linker. This is the step that you have missed.
If you are using visual stdio, check your project property vs your friend's project property and check link library path+ library name with .lib shoul be included. It seems in your friends computer is not getting the library to resolve the symbols. Compile time checking is done only with header files. While linking it should find the definition of yor function in library.
for command line:
from:http://social.msdn.microsoft.com/Forums/vstudio/en-US/6bcae3d1-85b6-471d-a4ee-7b455b21460b/how-do-i-link-libraries-that-are-sitting-in-different-directories-from-the-command-line?forum=vcgeneral
cl main.obj ab1.lib ab2.lib de1.lib de2.lib gh1.lib /Fetestmain.exe /link /LIBPATH:C:\test\ab /LIBPATH:C:\test\de /LIBPATH:C:\test\gh
The "/link" is very important...do not use "/LINK", the uppercase LINK is not recognised.
I have a large and complicated project that is finally getting unit tests. I've built googleTest 1.6.0 locally with Visual Studio 2010, the project files built with cmake as the README specifies.
This project has many dependent libraries that are statically and dynamically linked. Many of them proprietary. All attempts to link generate 220 such errors. Here is a sampling:
msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: void __cdecl std::_Container_base12::_Orphan_all(void)" (?_Orphan_all#_Container_base12#std##QEAAXXZ) already defined in gtest.lib(gtest-all.obj)
libcpmtd.lib(cerr.obj) : error LNK2005: "protected: char * __cdecl std::basic_streambuf >::_Gndec(void)" (?_Gndec#?$basic_streambuf#DU?$char_traits#D#std###std##IEAAPEADXZ) already defined in msvcprtd.lib(MSVCP100D.dll)
LIBCMTD.lib(setlocal.obj) : error LNK2005: _configthreadlocale already defined in MSVCRTD.lib(MSVCR100D.dll)
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
fatal error LNK1169: one or more multiply defined symbols found
I've tried the /NODEFAULTLIB flag, and I've tried to ignore just msvcprtd.lib, MSVCRTD.lib, and LIBCMTD.lib, as suggested, but then I suffer from unresolved symbols...
Both the project and googleTest are compiled with x64, /MP, /MDd, and no /clr.
I've been playing around with compiler flags, wondering if there's some sort of version mismatch. Dumpbin, to the extent with which I understand it, hasn't hinted anything I might understand. I was hoping for an er
It looks like your question is answered in Google Talk's FAQ. Make sure all your libraries use the /MD(d) setting.
You may get a number of the following linker error or warnings if you attempt to link your test project with the Google Test library when your project and the are not built using the same compiler settings.
LNK2005: symbol already defined in object
LNK4217: locally defined symbol 'symbol' imported in function 'function'
LNK4049: locally defined symbol 'symbol' imported
The Google Test project (gtest.vcproj) has the Runtime Library option set to /MT (use multi-threaded static libraries, /MTd for debug). If your project uses something else, for example /MD (use multi-threaded DLLs, /MDd for debug), you need to change the setting in the Google Test project to match your project's.
To update this setting open the project properties in the Visual Studio IDE then select the branch Configuration Properties | C/C++ | Code Generation and change the option "Runtime Library". You may also try using gtest-md.vcproj instead of gtest.vcproj.
I have a very strange problem. I have a project in VS2012 that links statically with another lib.
If I build project everything is fine.
However, if I REBUILD the project it will fail with link problems.
The lib is compiled, I do not compile it during the build.
It is no difference if I clean everything or building/rebuilding on top of previous build.
Build works, Rebuild - not!
Can anyone give me at least a clue - what different in those 2 commands? I do not even know how to start investigate the problem.
Supplemental:
To all the people that answered - You are trying to explain me the difference between the build and rebuild. Thank you, but I know it. You ignore the fact that I explained before:
I can completely clean previous results, delete OutDir, delete IntDir, delete everything produced by the compilation. still - Build work, Rebuild not.
In the explained above case - what is the difference between build and rebuild if you build the first time??
The reason I did not posted errors is that those are simply link errors telling me .lib is missing. While it is clearly not.
Here is the example:
1>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2872): warning RC4005: '_useHeader' : redefinition
1>
1>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2882): warning RC4005: '_on_failure' : redefinition
1>
1> Creating library D:\p4client\ProAudio\dev_main\ProAudio\XPlatform..\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\Products\WaveShell-DAE.lib and object D:\p4client\ProAudio\dev_main\ProAudio\XPlatform..\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\Products\WaveShell-DAE.exp
1>DefaultSwap.obj : error LNK2019: unresolved external symbol _ASI_UnregisterCustomByteSwapper#4 referenced in function _RemoveByteSwapper
1>DefaultSwap.obj : error LNK2019: unresolved external symbol _ASI_RegisterCustomByteSwapper#8 referenced in function _RegisterByteSwapper
1>PlugInLib.lib(PlugInUtils.obj) : error LNK2001: unresolved external symbol _imp_FicGestalt#8
1>PlugInLib.lib(CDSPProcess.obj) : error LNK2001: unresolved external symbol _imp_FicGestalt#8
1>PlugInLib.lib(CAdaptorPlugIn.obj) : error LNK2001: unresolved external symbol _imp_FicGestalt#8
1>CShellProcessGroup.obj : error LNK2019: unresolved external symbol _imp_FicGestalt#8 referenced in function "public: __thiscall CShellProcessGroup::CShellProcessGroup(void)" (??0CShellProcessGroup##QAE#XZ)
1>CEffectTypeRTAS.obj : error LNK2001: unresolved external symbol _imp_FicGestalt#8
1>PlugInLib.lib(CProcessGroupInterface.obj) : error LNK2001: unresolved external symbol _imp_FicGestalt#8
1>PlugInLib.lib(CProcessGroup.obj) : error LNK2001: unresolved external symbol _imp_FicGestalt#8
Maybe it will help to know that while running Build (Not rebuild) I will get the following warnings:
1>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2872): warning RC4005: '_useHeader' : redefinition
1>
1>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2882): warning RC4005: '_on_failure' : redefinition
1>
1> Creating library D:\p4client\ProAudio\dev_main\ProAudio\XPlatform..\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\Products\WaveShell-DAE.lib and object D:\p4client\ProAudio\dev_main\ProAudio\XPlatform..\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\Products\WaveShell-DAE.exp
1>PlugInLib.lib(C321ChipDSP.obj) : warning LNK4099: PDB 'vc110_ib_2.pdb' was not found with 'PlugInLib.lib(C321ChipDSP.obj)' or at 'D:\p4client\ProAudio\dev_main\ProAudio\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\vc110_ib_2.pdb'; linking object as if no debug info
1>PlugInLib.lib(CDSP.obj) : warning LNK4099: PDB 'vc110_ib_3.pdb' was not found with 'PlugInLib.lib(CDSP.obj)' or at 'D:\p4client\ProAudio\dev_main\ProAudio\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\vc110_ib_3.pdb'; linking object as if no debug info
1>PlugInLib.lib(CDSPUtils.obj) : warning LNK4099: PDB 'vc110_ib_4.pdb' was not found with 'PlugInLib.lib(CDSPUtils.obj)' or at 'D:\p4client\ProAudio\dev_main\ProAudio\VisualStudioBuildProducts\WaveShell-DAE\Win32\Debug\vc110_ib_4.pdb'; linking object as if no debug info
Thanks!
Build means compile and link only the source files that have changed since the last build, while Rebuild means compile and link all source files regardless of whether they changed or not.
Build is the normal thing to do and is faster. Sometimes the versions of project target components can get out of sync and rebuild is necessary to make the build successful. In practice, you never need to Clean.
'Build' will do an incremental build, basically going through each project in your solution, see if there has been a change since the last build, and if there is, build it again.
'Rebuild' will perform a clean on everything and build everything from scratch.
Edit: A more detailed answer link
If your static lib is another project in the same solution as the project that links to the lib, then you need to set a dependency between the two projects so that the build process will build the lib first and the other project second.
To do this, right-click on the Solution abd choose "Project dependencies" from the pop-up menu.
I am not sure if it is related. But you may want to check this thread (the symptom is reversed from yours though...):
VS2010 Unresolved External Symbol errors on build (but not rebuild)
I'm working on a project that already contains the gzip library as follows:
zlib\zlib.h
zlib\zlib.lib
zlib\zconf.h
I would like to use the gzip functions from this .lib but am getting the following errors:
Compress.cpp
Linking...
Compress.obj : error LNK2001: unresolved external symbol _gzclose
Compress.obj : error LNK2001: unresolved external symbol _gzerror
Compress.obj : error LNK2001: unresolved external symbol _gzwrite
Compress.obj : error LNK2001: unresolved external symbol _gzopen
.\Debug/files.exe : fatal error LNK1120: 4 unresolved externals
Error executing link.exe.
The link settings include:
Object/library modules: zlib.lib
Project Options:
zlib.lib
In the file using the gzX() functions, it
#include "zlib/zlib.h"
What else needs to be done here to use these functions?
Thank You.
EDIT: Using Visual Studio 6.0 C++
EDIT2: It turned out the static library I was using had the gz() functions taken out of them. The header file still had them which was misleading.
I grabbed the one off here to get zlib to build in windows. If you did the same, you may have forgotten to #define ZLIB_WINAPI before including zlib.h
you also need to add zlib.lib to your project's libraries:
Project properties->Linker->Input->Additional Dependencies.
When the build stops, ctrl-click on the URL to see the more verbose form of the log and check the actual command line passed to the linker. That at least will tell you whether the option to link against zlib is being respected. You may get other useful diagnostic output. One possibility could be that the architecture is different (eg you're building x64 but the lib is x86)
It turned out the static library I was using had the gz() functions taken out of them. The header file still had them which was misleading.