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.
Related
I have developed a simple (no COM) C++ DLL for VBA (Excel) in VS 2008, which works perfectly on Win 10 and Excel 2016, as well as on Win XP and Excel 2003, both during debug and release. I have developed it following this example.
Now, jumping to the issue, using the same recipe and piece of code I have developed the same DLL, but in VS 2015. The debug and release versions for x64 work perfectly, but when I want to release the DLL for X86, it throws me the following error:
1>defFile.def : error LNK2001: unresolved external symbol "func_name"
Additional info, the project has only 2 files, as in the example:
.cpp
.def
Anyone has an idea how to get over this link issue?
My feeling is that, there might be a setting that I overlooked or skipped!
If you need the code or the settings, I will happily provide them, but they should be as in the example!
Thanks!
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.
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 have followed the intrunctions here to the core.
And they run perfect on Windows 7 32 bit machine. But I use the same instructions with Windows 7 64 bit machine. I get the following error.
error LNK2019: unresolved external symbol _cvDestroyAllWindows referenced in function "void * __cdecl trial1(void *)" (?trial1##YAPAXPAX#Z)
and similarly for other openCV methods.
I have made changes in my Configuration Manager and added x64 to the Solutions Platform but still getting the errors.
You need to link the *.lib files in the project properties. They is a lib file for every header file included in the code. i.e. opencv2/core has lib opencv_core.lib
I have been trying for several hours now to link allegro 4.4 with visual studio 2010. I am using microsoft visual C++ 2010 express edition. Here is what I did:
I downloaded the windows binaries from http://www.allegro.cc/files/?v=4.4 (I downloaded the MSVC 2010 one)
I extracted the three folders in the zip archive to the following location "C:\allegro"
I launched MSVC and created a new windows console application
I created a main.cpp file
In the project properties I went to VC++ directories and set Include Directories to "C:\allegro\include"
In VC++ directories I set Library Directories to "C:\allegro\lib"
In Linker->Input I added "allegro-4.4.2-md.lib" to the additional dependencies.
In Configuration Properties->Debugging I set 'enviorment' to "PATH=c:\allegro\bin;%PATH%"
I applied all the changes and entered this simple program into main.cpp
#include <allegro.h>
int main()
{
return 0;
}
END_OF_MAIN();
When I tried to debug it I got two errors Error 1 error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup and Error 2 error LNK1120: 1 unresolved externals
I've been pulling my hair out in frustration! Can someone please help me out or point me in the right direction?
Well I feel like an idiot now but I figured it out after reading http://www.allegro.cc/manual/4/miscellaneous/frequently-asked-questions-(faq)/windows-problems/d4cf0624ded68003a11b4892102bbc66. I realized the problem is that I created a console application rather than a window application. I fixed this by going to Configuration Properties -> Linker -> System and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)" I hope this helps any else who runs into this problem.
You need to add this
Project Properties->Linker->Input->Additional Dependencies: edit and add the following
alld.lib