I'm using several libraries built through vcpkg (such as civet-web and prometheus-cpp), against my Visual C++ projects. When building x86 all is perfect, in x64 I get a bunch of linker errors:
error LNK2001: unresolved external symbol __CxxFrameHandler4
Searching online all references to this symbol/error are about specific projects, I cannot find what __CxxFrameHandler4 is and what problem this error is highlighting. I don't know if it's a problem with the way vcpkg is building the library, or a problem in my project or how to start looking for a solution.
I did find this blog article but it is in reference to a preview of VS2019, I cannot find any settings related to it: https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
If anyone can explain what this is all about it would be a big help.
I faced the same issues when trying to install and use cpr with vcpkg. I wanted to use cpr library in a VS2015 project.
Reason: I had VS2019 installed. vcpkg uses latest version of toolset Visual Studio.
Resolution: Add your own triplet or change existing such a way that your specified toolset is used. Adding did not work in my case so I changed existing "triplet" files in triplet folder in vcpkg. I wanted vcpkg to use toolset that comes with VS2015 (It's V140)
Content of x86-windows.cmake file
set(VCPKG_TARGET_ARCHITECTURE x86)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
set(VCPKG_PLATFORM_TOOLSET "v140")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v140")
Content of x64-windows.cmake file
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)
set(VCPKG_PLATFORM_TOOLSET "v140")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v140")
A more general answer is that this happens if you are mixing objects that were built with different platform toolsets, e.g.,
Visual C++ 2015 (v140)
Visual C++ 2017 (v141)
Typically, you (or someone else) may have built a dependency of your project with a different compiler version (platform toolset), and the fix it to change the platform toolset of either your project or the dependency (or use the correct build of the dependency, if you used a pre-built package)
I think you pointed out the right article which is
https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/
I faced a similar issue in linking 64-bit library built with VC143 toolset with a 64-bit Application built with VC141 toolset.
After adding the following properties to VC143 built static library project, I was able to build the application. This disables the new feature mentioned in the above article (Exception Handling Smaller)
VS2019->Properties->C/C++->Command Line add '-d2FH4-'
VS2019->Properties->Linker->Command Line add '-d2:-FH4-'
Related
I just built the project that I'm supposed to fix. I double checked that correct DLLs are loaded - the project uses Qt 5.3.0, and the dlls are loaded from 5.3.0 directory. I am not sure where is the problem. Is my project using incorrect Qt headers? Or is the DLL build incorrectly?
I'm building in Debug with Visual Studio 2017. The DLLs are also built with visual studio. I tried Vidual Studio 2010 instead, since it's 2010 project, but the error was the same.
Are you in release or debug mode? QtCoded.dll is related to debug profile.
Another explanation could be how your Qt was built.
If I remember correctly Qt was built with msvc2015 so you have to use msvc2015 to build your exe with Visual Studio and it is not possible to use a msvc version before or after that.
Please remeber that you can't use the Qt framework built with mingw with msvc.
In other words I suggest you to check which version of msvc are you using with Visual Studio and which version of Qt framework.
Regards.
In my case, the problem was following:
One of the sub-projects was accidentally configured to use Qt 5.6.1, whereas the rest of the solution used 5.3.0. I found out by opening the result binary in dependency walker.
I just had the same problem with QT 4.
The solution was found on this post: The procedure entry point could not be found
I ran into the same problem, and in my case, this was due to the fact that I had two versions of the same library installed on my computer.
In the end, the problem was that I was linking my program against the new LIB file while my PATH was pointing to the old DLL. When the library version number is not included in the LIB or DLL file names, it is very easy to mix the versions.
I my case I was using a QtCored4.dll and others from an older version of QT. The solution was copy the DLLs directly from my QT installation directory which was used to build the application (as it was set by my QTDIR environment variable): C:\Qt\4.8.7\bin to my application directory.
After reinstalling Visual Studio 2010, I recompiled the code and encountered the following error:
Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt'
A solution mentioned that the lib file is incompatible and I need to install Visual Studio 2010 SP1. I did that, and now it has been solved.
I am wondering how can I check whether a lib file is created by SP1 or not?
I tried dumpbin, but I cannot find the version in its result.
It was not an incompatibility with your LIB file that caused the problem here, so checking the version of the linker that created it would not be a solution anyway.
The issue is that cvtres.exe (used internally by the linker toolchain) depends on a particular DLL (msvcr100_clr0400.dll) shipped with VS 2010 RTM. When you update to a later version of the .NET Framework (e.g., by installing .NET 4.5 or installing a later version of VS), this DLL is replaced. That stops cvtres.exe from working.
The reason why installing VS 2010 SP1 fixes it is because it actually modifies the cvtres.exe application to break the dependency. And now that all pieces of the linker toolchain work, you can compile and link the code without error.
Of course, there are other problems you can have when you start mixing libraries created by different versions of the compiler and/or linker. They aren't guaranteed to create 100% compatible output, so mixing them is not supported (at least not between major versions, I'm uncertain about how this rule applies to service packs).
In general, it's best to just recompile all libraries whenever you update your build system. The only time you wouldn't do this is if you didn't have the source code, in which case, you need to be very careful about updating your build system, lest you introduce gratuitous incompatibilities.
As far as determining the version of the linker that prepared a particular binary, using dumpbin.exe (included with the SDK) is exactly the correct approach. For static libraries, run the following command from the Visual Studio SDK Command Prompt:
dumpbin /rawdata:1 MyLibrary.lib
You'll see the assembly manifest, which will include the full path to the compiler used to build the library as well as the version of the CRT that it depends upon.
For dynamic libraries (i.e., DLLs) and executables, run the following command:
dumpbin /headers MyApp.exe
Look under the "Optional Header Values" section (not actually optional) for the version of the linker, along with a timestamp of when it was generated.
Note that you're very unlikely to find this information in release builds of a library or binary.
I wrote a tool that many users would use on their computers. I noticed however, that users who do not have visual studio installed, cannot open my executable. The error says that msvcp100.dll is missing. I found in internet a redistributable package from microsoft, that should apparently provide these dlls. My question is: is there another way to bypass this problem? Something like an option in the project properties?
Yes, you can change a compiler setting to link the C++ standard library classes into your program instead of having a dependency on the DLL. Right-click your project in the Solution Explorer window, Properties. Switch to the Release configuration (upper left). C/C++, Code Generation, Runtime Library setting. Select /MT.
Only do this when you only have a single monolithic EXE. When you use your own DLLs then you really need msvcr100.dll and msvcp100.dll so that the runtime library gets shared between all modules.
It is part of C++ runtime and the target machine needs it. THere are couple of ways to address it.
Please check following link from Microsoft MCVCP100.DLL
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?
I work on C/C++ using Visual Studio 2008. I believe that I am not concerned about which runtime libraries are being used by my code as I have the developer setup. But when the executable is shipped, the runtime libraries being used need to be shipped alongwith. Am I right?
If yes, how can I identify which shared libraries are actually getting used? Or are there any libraries that we can ship without having to know this?
You're correct, you need to ship a version of the C runtime libraries that matches the version you linked your application against. If you're compiling with Visual Studio 2008, then you want to use the Microsoft Visual C++ 2008 Redistributable Package. As other folks mentioned, you can inspect your application's manifest file to see exactly which version of the C runtime libraries it's linked against.
Before shipping, it's always best to install your product on a clean (i.e., non-developer) virtual machine and run Microsoft's Dependency Walker utility to verify that your application uses the correct C runtime libraries.
you need to ship dll files with you.
you can guess most of them and for the rest you can use a program "Dependency Walker" which shows you dependencies of the executable.
Look at the generated manifest file to see which version of the CRT you need to ship with. It's possible to change which version of the CRT you link to as seen here but it doesn't seem to be recommended.