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.
Related
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-'
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.
I have a Visual C++ solution with static and dynamic libraries, and one executable that uses these libraries. I'm currently upgrading from Visual Studio 2010 to Visual Studio 2015, I also upgraded the SDK version the projects use to 10.0.10586.0 (Windows 10).
Everything compiles and links correctly, except for one linker warning:
uuid.lib(unknwn_i.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
uuid.lib is part of the Windows SDK. It might have been compiled with /GL, but does that mean that every executable that gets linked against this library must use /GL? That would be pretty constraining. By the way, if I switch to Windows SDK version 8.1 (but still using Visual Studio 2015), the warning goes away.
I have a feeling that something else might be wrong here (even though the linker points to a very specific location), because I found zero Google references of this particular error with this particular object file, which is very strange...
Any ideas?
Edit:
The warning is present in both Debug and Release builds
According to link.exe with /VERBOSE, X.obj (and only that object) in my executable project is referencing unknwn_i.obj, that's why it is "pulled in". This project does not use /GL nor /LTCG at all (checked the project properties, each cpp file's properties in the project, and there are no "standalone" property sheets in the solution)
I also tried removing all libraries linked to the exe project from it's linkage list. When only the default ones were linked (kernel32.lib, uuid.lib, etc.), the warning still persisted (aside from tons of unresolved references, but that's because I intentionally removed libraries). So it's not external libraries that cause this issue.
I've been sent a sample app for a newly minted SDK, and I can't compile it - it won't compile at all in Visual Studio Express for reasons of ATL, and that seems to be the only version of VS 2010 that Microsoft still makes available. So I'm trying to compile it in VS 2012 Professional, but it gives me error LNK2038. From what I can gather e.g. from this thread, the problem is down to trying to use .lib files compiled for 2010 in the 2012 version. Since I'm not the one who compiled the .lib, and I don't have the code for it, and VS 2010 is inaccessible, I'm really not sure what to do about this unless the original authors recompile it. Any suggestions? Something basic I'm missing? Many thanks for any help.
Library files cannot be reused across different versions of the compiler. You will need to do one of the following:
Compile your project with the same version of the compiler used for creating the library files you have.
Obtain new library files from the owner of the code, compiled using the same compiler you are now using.
Obtain the source code for the libraries, and compile new versions of them yourself.
Rewrite the code you own to not depend on the libraries you cannot control, since your build environment does not allow for their use.
I know this has been asked in other places and answered, but I'm having issues with MS Visual Studio 2010. I've developed a C++ executable but if I run the Release version on a machine that doesn't have the VC++ runtime library (ie, msvcr100d.dll), I get the "program cannot start because msvcr100d.dll is missing from your computer" error.
This is weird for two reasons:
Why is it trying to link with the debug version of the redistributable?
I tried applying this fix, setting the runtime library setting to /MT instead of /MD (multi-threaded DLL), but that only made the problem worse (if I manually copied msvcr100d.dll, it then said it couldn't find msvcp110.dll).
How can I package the runtime library with my executable so that I can run it on machines that don't have MS VC 2010 or the redistributable installed?
I know it's considered a security risk to include a copy of the DLL since it won't ever be updated, but my goal is just to send this executable to a few friends in the short term.
You definitely should not need the debug version of the CRT if you're compiling in "release" mode. You can tell they're the debug versions of the DLLs because they end with a d.
More to the point, the debug version is not redistributable, so it's not as simple as "packaging" it with your executable, or zipping up those DLLs.
Check to be sure that you're compiling all components of your application in "release" mode, and that you're linking the correct version of the CRT and any other libraries you use (e.g., MFC, ATL, etc.).
You will, of course, require msvcr100.dll (note the absence of the d suffix) and some others if they are not already installed. Direct your friends to download the Visual C++ 2010 Redistributable (or x64), or include this with your application automatically by building an installer.
For me the problem appeared in this situation:
I installed VS2012 and did not need VS2010 anymore.
I wanted to get my computer clean and also removed the VS2010 runtime executables, thinking that no other program would use it.
Then I wanted to test my DLL by attaching it to a program (let's call it program X).
I got the same error message.
I thought that I did something wrong when compiling the DLL.
However, the real problem was that I attached the DLL to program X, and program X was compiled in VS2010 with debug info. That is why the error was thrown.
I recompiled program X in VS2012, and the error was gone.
This problem explained in MSDN Library and as I understand installing Microsoft's Redistributable Package can help.
But sometimes the following solution can be used (as developer's side solution):
In your Visual Studio, open Project properties -> Configuration properties -> C/C++ -> Code generation
and change option Runtime Library to /MT instead of /MD
Usually the application that misses the .dll indicates what version you need – if one does not work, simply download the Microsoft visual C++ 2010 x86 or x64
from this link:
For 32 bit OS:Here
For 64 bit OS:Here
I got the same error.
I was refering a VS2010 DLL in a VS2012 project.
Just recompiled the DLL on VS2012 and now everything is fine.
Debug version of the vc++ library dlls are NOT meant to be redistributed!
Debug versions of an application are not redistributable, and debug
versions of the Visual C++ library DLLs are not redistributable. You
may deploy debug versions of applications and Visual C++ DLLs only to
your other computers, for the sole purpose of debugging and testing
the applications on a computer that does not have Visual Studio
installed. For more information, see Redistributing Visual C++ Files.
I will provide the link as well : http://msdn.microsoft.com/en-us/library/aa985618.aspx