We're facing a strange issue and I've run out of troubleshooting ideas. The issue is that on some machines, which are running Visual Studio 2017 Community, we get reports that our project (which is CMake based) gets linker errors like this:
17>------ Build started: Project: ndt, Configuration: RelWithDebInfo x64 ------
17> Creating Library E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.lib and object E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.exp
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol edKJPOs664VT referenced in function "void __cdecl CheckLibraryLicenses(struct NodeInput*,...)
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol zzPIPSGJWa referenced in function main
...
17>E:\NDT_3_0\19_sep18\qualnet\bin\exata_so.exe : fatal error LNK1120: 17 unresolved externals
(Apologies if there are typos: for some reason they sent us a screenshot of the text instead of just a copy-and-paste of the text, so I'm transcribing. However, the parts I'm leaving out contain no mention of errors trying to open lmgr.lib which defines these symbols.)
The strange thing is, we can't reproduce these errors here when we do a fresh clone of the same Bitbucket repository they're using and follow the same build instructions. About the only difference I can tell is that our machines are running Visual Studio 2017 Professional. (Though I'm certainly not sure if this is actually the cause of the behavior differences.)
So far, what we've checked:
The library that contains the unresolved external symbols passes sha1sum checks so their Git client isn't corrupting the library binary file lmgr.lib - and same for the ndt-main-windows-x64-vc14.obj file.
The generated ndt.vcxproj project contains (the correct path to) lmgr.lib in the "Linker -> Input -> Additional Dependencies" property, as expected.
The lmgr.lib file does define the mentioned symbols (verified by Cygwin binutils nm).
On their machines, they get essentially the same linker errors whether using the Visual Studio 15 2017 Win64 generator and building from the IDE, or using the NMake Makefiles generator and building from a command prompt. Both configurations work fine on our machines.
I was wondering if somebody out there might have any ideas on why some machines might be failing to find the symbols in lmgr.lib whereas our machines have no problems completing the link stage.
(Possibly relevant: lmgr.lib contains the FlexNet Publisher licensing libraries where the symbols in both lmgr.lib and ndt-main-windows-x64-vc14.obj have been obfuscated by Flexera's lmstrip tool.)
It turned out that when we asked them to upgrade their Visual Studio 2017 Community installation to the latest service pack release, then after that the linker errors disappeared.
Related
So here's the issue:
I have an old software system written in C++ and built originally on Win Xp with VS 2005 SP1. Most of the solutions in this code-base are reliant on third-party DLLs that are registered using regsvr32.exe. Without this step VS 2005 throws out Linker errors. After registration everything works like a charm.
I've been able to successfully rebuild the project using Win 10 and VS 2005 and now I'm trying to do the same with newer version of VS, namely VS 2019. For a single test solution I was able to resolve compilation errors, but it seems that VS 2019 Linker cannot find DLLs that should have been registered with regsvr32, since I'm getting the same Linker errors that I have have been getting with VS 2005 prior to registering DLLs.
I'm most certainly sure that this is due to VS 2019 "not seeing" DLLs that were registered with regsvr32. Thus the question: does anybody have any idea how to make VS 2019 discover those DLLs?
DLLs and target for compiler are 32bit. I've been using SysWOW64\regsvr for registering 32 bit DLLs. The folder with DLLs is in $PATH. Also the folder with DLLs is set in Project -> Project Properties -> VC++ Directories -> Library Directories setting of VS 2019
Edit:
Linker Errors in both cases (before using regsvr32 with VS 2005 and with VS 2019) are of form:
...
1>RecordSet.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall IDatabase::~IDatabase(void)" (__imp_??1IDatabase##QAE#XZ) referenced in function "public: void * __thiscall IDatabase::`scalar deleting destructor'(unsigned int)" (??_GIDatabase##QAEPAXI#Z)
...
Followed by fatal error LNK1120: 17 unresolved externals
I'd be glad to get any pointers.
I am a Java developer whose project needs one bit of C code (DLL) that I recompile every few years when I upgrade my machine. My new machine is AMD-64bit (Windows8) so the old 32-bit DLL will not run.
I installed MS Visual Studio 12. I copied the old project to the new machine. VS migrated it. I selected build and prayed that it would work. Of course, it did not.
I get these two errors:
1>IcmpSocketN.obj : error LNK2001: unresolved external symbol __imp__printf
1>IcmpSocketN.obj : error LNK2001: unresolved external symbol __imp___ftime64_s
1>C:\temp\new_March09\ATM\Release\AtiICMP.dll : fatal error LNK1120: 2 unresolved externals
These are two standard functions so I am assuming that VS installed them somewhere.
When I did the install I selected the C++ foundation libraries. When I look at the project properties I see that the only platform option is Win32. This is a 64-bit machine. I do not know if that matters or not.
The VS install on my old machine has a VC subdirectory with a bunch of libraries in it. The new install has no such directory.
Is there some .lib or .dll that I have to download independently of the VS install? Some environment variable change?
thanks
I get this error when I run my sln with Visual studio 2005version 8.0.50727.42 ,.NET framework version 2.0.50727 .
error LNK2001: unresolved external symbol
but I don't get the error while running the same sln through Visual Studio 2005 with .NET framework of little higher version.
I reinstalled the previous version mentioned above.but still having the same linking errors.
Requirement is to build the code with the first version mentioned above.
Please suggest way ot.
Note: the project properties are set the same while building the code with two different version mentioned above.
Try setting the /VERBOSE flag for your linker (Note: Make sure that you set it for the linker). Then look through all included libraries and verify that the one that contains the symbol in question is linked properly.
EDIT: Also note that you will not get a proper warning when linking (or rather failing to link) against 64-bit libraries in a 32-bit project.
I've created an OpenGL (GLEW) project in VS2012 and it is working perfectly. Now I've moved the project to VS2013. I've created a new project and set the project's environment the same as I did in VS2012:
Character Set:--------------Use Multi-Byte Character Set
Include Directories:--------C:\Foo\glew-1.9.0\include
Library Directories:--------C:\Foo\glew-1.9.0\lib
Additional Dependences:-opengl32.lib; glu32.lib; glew32.lib
Runtime Libary:-------------Multi-Threaded Debug (/MTd)
All code is exactly the same as before, but when I run the program, I get this error:
Error 1 error LNK2019: unresolved external symbol _main referenced in
function ___tmainCRTStartup c:\FooBar\...\Projects\OpenGL\OpenGL\LIBCMTD.lib(crt0.obj)
OpenGL
I can't see why this same project with the same settings and code doesn't work when it is an exact duplicate.
Hi #SpicyWeenie LIBCMTD is the debug version of the static multi-threaded C runtime library, and according to Microsofts licensing you cannot use than in the release version of code, I would check you are compiling in debug mode:
in debug mode use /MTd as the runtime library
in release mode use /MT as the runtime library
This will hopefully help, if not, then clean your project before building, and if that does not help either, apply liberally with swearing before creating a new project and ensuring it is a Windows Console Application and not a Windows Application (the last one has been the most common cause of the exact error you are describing for me, and happens mostly to me when moving between versions of Visual Studio (2008 to 2010 or 2010 to 2012)
Sincerely hope this helps, but if it doesnt let me know and maybe I can figure out whats wrong:)
I was building a win32 static library project and on debug mode it compiles without any problem but when I changed the build mode to release I get this link errors. Can anyone suggest what is going wrong here?
Error 2 error LNK1120: 1 unresolved externals C:\Users\serak\Desktop\Cimg Wrapper\Release\nativeWin32console.exe nativeWin32console
Error 1 error LNK2001: unresolved external symbol _main C:\Users\serak\Desktop\Cimg Wrapper\nativeWin32console\MSVCRT.lib(crtexe.obj) nativeWin32console
I think in the Project Propierty Pages (rigth click the project in VS solution explorer) of the project change for ALL configuration and platform, the Configuration Propiertie->Project Defaults->Configuration Type-> from Aplication to Static Libraries: you probably have set it for debug but not for the release configuration.
If you're using Visual Studio, you need to add any external libs that you are linking against in release mode as well. Chances are you have already done this for the debug build configuration, but it does not transfer to release by itself.