I am working on a solution with 100+ files. I am using MS Visual Studio 2015 Pro. Compiling it is fine, problems come at link stage.
LINK complains on one of the project's library but only gives me the error number.
The command line (simplified) used is the following:
LINK.exe /NOLOGO /MANIFEST /IMPLIB:C:\\MySolution\\myownlib.lib -LARGEADDRESSAWARE -subsystem:console -MACHINE:X86 -DEBUG -INCREMENTAL /DLL File1.cpp.1.o File2.cpp.1.o File3.cpp.1.o File4.cpp.1.o /OUT:C:\\MySolution\\myownlib.dll
The only output I get is the following:
File1.cpp.1.o : error LNK2005:
File2.cpp.1.o : error LNK2005:
File3.cpp.1.o : error LNK2005:
File4.cpp.1.o : error LNK2005:
File1.cpp.1.o : error LNK2001:
File2.cpp.1.o : error LNK2001:
File3.cpp.1.o : error LNK2001:
File4.cpp.1.o : error LNK2001:
I cannot find any clue as to why the linker does not complains with the duplicated symbols nor the unresolved ones. Since the lib owns more than 80 objects, and nearly all of them is listed, finding the erroneous symbol(s) is like looking for a needle in a haystack!
EDIT : I do not compile using the IDE, I use the developer command prompt to build. Migrating the project in Visual Studio is not frankly possible as the program I am working on has never been imported under Visual Studio, we only use the compiler/linker. Moreover, a colleague of mine working on the project does not experience such troubles. It seems that something is going on under my environment...
EDIT 2 : Full installation repair fixed the problem.
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 am trying to build the BGSLibrary for Windows 10, cmake 3.9, with python support, built with opencv 3.1 and boost 1.64.0 with Visual Studio Community 2017.
Can someone more familiar with Visual Studio interpret this error for me. The c++ seems to compile great, but then project solution fails. It starts by building all the .obj files
2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\Lib.exe /OUT:"C:\Users\Ben\Documents\bgslibrary\build\libbgs.lib" /NOLOGO /machine:X86 libbgs.dir\Release\AdaptiveBackgroundLearning.obj
2>libbgs.dir\Release\AdaptiveSelectiveBackgroundLearning.obj
2>libbgs.dir\Release\CodeBook.obj
2>libbgs.dir\Release\DPAdaptiveMedian.obj
2>libbgs.dir\Release\DPEigenbackground.obj
The general error reads.
5>libbgs.lib(LBSP.obj) : error LNK2019: unresolved external symbol "public: virtual void __thiscall cv::Feature2D::read(class cv::FileNode const &)" (?read#Feature2D#cv##UAEXABVFileNode#2##Z) referenced in function "[thunk]:public: virtual void __thiscall cv::Feature2D::read`vtordisp{4294967292,0}' (class cv::FileNode const &)" (?read#Feature2D#cv##$4PPPPPPPM#A#AEXABVFileNode#2##Z)
But the file LBSP.obj compiled fine just 100 lines earlier? I can see it here.
This file was created during the build, why can't it link? Where do I need to add this dir?
I'm reading other SO questions that this error may mean I need to add additional paths, which was done pre-VS2017 by going to PROPERTIES->LINKER->ADDITIONAL DEPENDENCIES. I don't see this option or structure anymore.
3>C:\Users\Ben\Documents\opencv\modules\core\include\opencv2/core/types_c.h(894)
This was a Cmake path error, not a Visual Studio error. Adding OpenCV/bin to path solved this.
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.
I am running into an issue with compiling gdal 1.11.0 following the guide here: http://trac.osgeo.org/gdal/wiki/BuildingOnWindows
I am able to run nmake /f makefile.vc MSVC_VER=1800 WIN64=YES but when doing the install it fails with the following erros:
Creating library gdal_i.lib and object gdal_i.exp
LINK : error LNK2001: unresolved external symbol _OGRFeatureStylePuller
LINK : error LNK2001: unresolved external symbol _OSRValidate
LINK : error LNK2001: unresolved external symbol _OPTGetProjectionMethods
LINK : error LNK2001: unresolved external symbol _OGR_G_GetPointCount
LINK : error LNK2001: unresolved external symbol _OGRRegisterAll
LINK : error LNK2001: unresolved external symbol _GDALSimpleImageWarp#36
LINK : error LNK2001: unresolved external symbol _GDALReprojectImage#48
LINK : error LNK2001: unresolved external symbol _GDALComputeMedianCutPCT#32
LINK : error LNK2001: unresolved external symbol _GDALDitherRGB2PCT#28
LINK : error LNK2001: unresolved external symbol _OCTNewCoordinateTransformation
#8
gdal111.dll : fatal error LNK1120: 10 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\amd64\link.EXE"' : return code '0x460'
Stop.
Is that something I can do anything about or is it something thats broken in the source downloaded from http://trac.osgeo.org/gdal/wiki/DownloadSource
The answer provided by Poul is not right. I finally find a way to fix this problem:
Find the nmake.opt file under GDAL home folder, open it and search for the definition of 'SYM_PREFIX'. Then change 'SYM_PREFIX=_' to 'SYM_PREFIX=' (remove the underscore).
Find the makefile.vc file under GDAL home folder, open it and search for the first definition of 'BASE_INCLUDE' (The other definition is just below it, do not change the wrong one).
Change from
BASE_INCLUDE = /INCLUDE:_GDALSimpleImageWarp#36 /
/INCLUDE:_GDALReprojectImage#48 /
/INCLUDE:_GDALComputeMedianCutPCT#32 /
/INCLUDE:_GDALDitherRGB2PCT#28 /
/INCLUDE:_OCTNewCoordinateTransformation#8 $(VB6_SAFEARRAYSYM)
to:
BASE_INCLUDE = /INCLUDE:$(SYM_PREFIX)GDALSimpleImageWarp /
/INCLUDE:$(SYM_PREFIX)GDALReprojectImage /
/INCLUDE:$(SYM_PREFIX)GDALComputeMedianCutPCT /
/INCLUDE:$(SYM_PREFIX)GDALDitherRGB2PCT /
/INCLUDE:$(SYM_PREFIX)OCTNewCoordinateTransformation $(VB6_SAFEARRAYSYM)
.
In short, replace the '_' with $(SYM_PREFIX), and remove the '#number'.
According to some webpages, this problem may be caused by the change of AMD64 vc++ compiler handling undecorated symbols.
It turned out that the arguments could not be passed on command line and needed to be changed in the config file.
I have same problem and after set right MSVC_VER(mine VS 2012), problem is solved.
Nmake Command:
nmake /f makefile.vc MSVC_VER=1800 WIN64=yes
MSVC Versions:
MSVC++ 9.0 _MSC_VER == 1500 (Visual Studio 2008)
MSVC++ 10.0 _MSC_VER == 1600 (Visual Studio 2010)
MSVC++ 11.0 _MSC_VER == 1700 (Visual Studio 2012)
MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013)
MSVC++ 14.0 _MSC_VER == 1900 (Visual Studio 2015)
MSVC++ 14.1 _MSC_VER == 1910 (Visual Studio 2017)
You can pass additional arguments into the build by uncommenting parts of the nmake.opt file. The below commands worked for me after invoking the batch file located at
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\"
with vcvarsall.bat amd64
nmake /f makefile.vc MSVC_VER=1800 WIN64=yes
nmake /f makefile.vc install MSVC_VER=1800 WIN64=yes
nmake /f makefile.vc devinstall MSVC_VER=1800 WIN64=yes
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)