I am using Microsoft Visual Studio 2011 Professional Beta
I am trying to run the OpenCV C++ files (http://opencv.willowgarage.com/wiki/Welcome) that I have compiled using cMake & the Visual Studio Complier.
However when I go to debug the project I get 600+ errors most of them being:
error LNK2026: module unsafe for SAFESEH image.
Apparently these files are in the opencv_ffmpeg project but I couldn't find them, I have had a look at the safeseh Safe Exception Handlers page on the Microsoft help page but I couldn't find any definitive answers.
I was wondering if anyone else has had this problem and if they managed to fix it.
Disabling option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab helped me.
From the comments:
This happens when you link an .obj or .lib that contains code created by an earlier version of the compiler. Which of course would be common if you downloaded a binary for opencv_ffmpeg instead of the source. You can turn the linker option off but then you'll still have a CRT version incompatibility that can byte. Rebuild the library from source. – Hans Passant May 15 at 13:01
Thanks for the help, it worked – Aaron Thompson May 17 at 14:50
If you got this error while building ZLIB in Visual Studio here is the solution. Look for contrib\masmx86\bld_ml32.bat and add /safeseh as a option
Before
ml /coff /Zi /c /Flmatch686.lst match686.asm
ml /coff /Zi /c /Flinffas32.lst inffas32.asm
After
ml /safeseh /coff /Zi /c /Flmatch686.lst match686.asm
ml /safeseh /coff /Zi /c /Flinffas32.lst inffas32.asm
Other way is to add some SEH handler (empty for example) to asm files and compile them with /safeseh option, then compile other code normally with /SAFESEH:YES compiler option.
Empty SEH handler:
.safeseh SEH_handler
SEH_handler proc
;handler
ret
SEH_handler endp
Your mileage may vary, but none of the above suggestions worked for me (although I did not try rolling my own asm exception handler).
What did work was to select build target Release/x64.
I am running Windows 10 on a 64-bit machine, and using Visual Studio 2015.
The target Release/Win32 works, too. I guess the main thing is to pick "Release".
Related
I've been following this youtube tutorial to begin learning about Assembly: https://www.youtube.com/watch?v=W3roB5sRg4o&list=PLRwVmtr-pp05c1HTBj1no6Fl6C6mlxYDG&index=2
And everything's been going fine until I switch the build from debug to release, returning two errors: "module unsafe for SAFESEH image", and "unable to generate SAFESEH image". The thing is that I've deleted everything except for the External Dependencies folder, meaning that I don't have a vast selection of properties to choose from.
Here's a screenshot to my Visual Studio environment:
And here's another screenshot of my properties:
I'm a bit confused, since some other forums say to just change a setting, but since I deleted those default project folders I don't have it. Or is it something simple that I'm missing?
I found a comment saying to replace the old build command from ml /c /Cx /coff "%(FullPath)" to ml /c /Cx /coff /safeseh "%(FullPath)" (notice the addition of /safeseh), which resolved the issue.
I want to use openCV in my Qt project. But the release build crash and mixing release and debug causes bugs. So I made search and found that building openCV on my very computer setting the same flags (optimization flags) that my project may help.
So I used cmake to generate the openCV project, and open the openCV.sln in my visual studio. But even when I disable the optimization in the properties, the detailed log output shows me that there's /O2 in the cl.exe command line.
Any one get a solution? I don't know well how to use Visual Studio, maybe I can build project from command line?
I want to rebuild Crypto++ via MSVC 2013 so when I am using the library to be able to build my project with /MD or /MDd, NOT /MT or /MTd, because I am using QT 5.5.1 with MSVC2013 32bit compiler and it seems if I want to make GUI interface - it is using /MD or /MDd! In this article in section Static Versus Dynamic Linking is mentioned the necessity for rebuilding (not building) and how you can see from my other question I did it, but it is only working for debug mode. For Release mode the errors from 117 go to 53, but again the same old error occures:
cryptlib.lib(cryptlib.obj):-1: error: LNK2038: mismatch detected for
'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value
'MD_DynamicRelease' in main.obj
I am doing just what I mentioned here
I want to rebuild Crypto++ via MSVC 2013...
OK, so the pain points here are the Microsoft changes to MSBuild at 2010. To make matters worse, VCUpgrade does a rather poor job of up-converting projects.
To help users with the upgrade process, Crypto++ provides a file called vs2010.zip. The archive contains the pre-converted solution file, project files and filters for Visual Studio 2010 and above. The files were released in October 2015 with a 5.6.3 Release Candidate.
The upgraded solution files are mostly successful. They build 20 of 24 configurations properly from the IDE. 4 of them fail on the first attempt; but the process recovers on the second attempt and builds all 24. We know its a dependency/ordering issue, but we don't know how to solve it. There's an open question on Stack Overflow at How to control order of Batch Build → Build All.
There is now a page on the subject of Visual Studio 2010 and VCUpgrade. See Visual Studio on the Crypto++ wiki.
In this article ...
I wrote that article years ago. You are on the right track.
I did it, but it is only working for debug mode. For Release mode the errors from 117 go to 53, but again the same old error occures:
cryptlib.lib(cryptlib.obj):-1: error: LNK2038: mismatch detected for 'RuntimeLibrary':
value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj
We added a ZIP file for you. The ZIP is a pre-converted Visual Studio 2010 solution and project files that utilizes dynamic runtime linking (/MD and /MDd). (Its not really just you since a lot of folks have asked about it over the years).
The solution to your problems are:
download vs2010-dynamic.zip from the Crypto++ wiki
unzip over top of the exiting Crypto++ distribution files.
I am using cryptopp from source with /MD, built on vs2013 using the latest cryptopp version (5.6.2). You want to be up to date on encryption or security software, plus they may have fixed platform build issues.
The issues you cite sound like intermediate files from building a project with /MT set, even if it was later changed to /MD (although it is dangerously easy to forget to change the drop-down to "all configurations", and change just the debug settings in one project).
First clean solution, then make sure you change every project to /MD in [bold]all configurations[bold], and clean solution again. Now search for and delete any debug or release folders and .obj .lib .dll files, because I don't trust "clean solution". It can only get files it intends to build under the current settings, but the linker might find more in the link search (/verbose:lib).
Then rebuild all.
I am currently modifying on a open-source project to suit my own need, however, the project to be built (or compiler) requires me to add a /EHsc option to cl.exe
I am using Microsoft Visual Studio 2012 to work on the project. I have been searching long enough but I cannot find the solution still.
Is it possible to add a flag via MS Visual Studio 2012? Because I saw the output log displaying that compiler (cl.exe) compiled with various flag in this project such as /nologo /c /WX.
How can I add the options to cl.exe with this IDE?
Project working on : SumatraPDF
[Edit #1] After reading the first answer provided below, this is the screen I got, it doesn't seem there is an option to do so.
Update: From the screenshot you posted, it seems the SumatraPDF project is NMake-based.
Therefore, you will have to add /EHsc to the build command line, using the NMake property page described here, or edit the Makefile directly.
Original, misguided answer follows:
Per MSDN:
To set this compiler option in the Visual Studio development
environment
Open the project's Property Pages dialog box. For details, see How to: Open Project Property Pages.
Select the C/C++ folder.
Select the Code Generation property page.
Modify the Enable C++ Exceptions property.
Or, set Enable C++ Exceptions to No, and then on the Command Line
property page, in the Additional Options box, add the compiler option.
Issue
I wrote a C++ project called 'Foo' using Microsoft Visual Studio 2005 Verison 8.0.50727.762 (SP.050727-7600) on Windows XP Professional Version 2002 Service Pack 3. I built the project into Foo.exe. Then, I copied the file Foo.exe to a Windows Server 2003 Enterprise Edition Service Pack 2. When I tried to run it, it failed with this error,
C:\foo.exe
The application has failed to start because the application configuration is incorrect.
Reinstalling the application may fix the problem.
In Event Viewer > System, three events were logged.
Event ID: 32; Source: SideBySide
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Resolve Partial Assembly failed for Microsoft.VC80.CRT.
Reference error message: The referenced assembly is not installed on your system.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe.
Reference error message: The referenced assembly is not installed on your system.
Installing Microsoft Visual C++ 2005 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=3387
Installed it. The installer created a folder called C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.
The version of this software as found from 'Add or Remove Programs' was '8.0.50727.42'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Installing Microsoft Visual C++ 2005 SP1 Redistributable didn't fix it
Downloaded vcredist_x86.exe from http://www.microsoft.com/download/en/details.aspx?id=5638
Installed it. The installer created a folder called: C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.
The version of this software as found from 'Add or Remove Programs' was '8.0.56336'.
On trying to run C:\foo\foo.exe, I got the same errors I described above.
Copying CRT DLLs and manifest from the same machine (where I'm running the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
to C:\foo.
Next, I copied
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
When I tried running C:\foo\foo.exe this time, it didn't work. I repeated this thing again with the DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 and the corresponding manifest file. It didn't help as well. I got the same error.
In both cases, I got the following errors in Event Viewer > System.
Event ID: 34; Source: SideBySide
Component identity found in manifest does not match the identity of the component requested
Event ID: 58; Source: SideBySide
Syntax error in manifest or policy file "C:\foo\Microsoft.VC80.CRT.MANIFEST" on line 4.
Event ID: 59; Source: SideBySide
Generate Activation Context failed for C:\foo\Foo.exe. Reference error message: The manifest file contains one or more syntax errors.
Copying CRT DLLs and manifest from the Windows XP machine (where I built the EXE) didn't fix it.
I copied msvcm80.dll, msvcp80.dll and msvcr80.dll from
C:\winnt\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 of Windows XP machine (where I developed and built foo.exe)
to C:\foo of Windows Server 2003 (where I am trying to run foo.exe).
Next, I copied
C:\winnt\winsxs\Manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700.manifest
to C:\foo and renamed it to Microsoft.VC80.CRT.manifest.
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
On trying to run C:\foo\foo.exe now I got the same errors mentioned in the previous section.
Copying CRT DLLs and manifest from Visual Studio folder fixed it.
Copied msvcm80.dll, msvcp80.dll, msvcr80.dll and Microsoft.VC80.CRT.manifest from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT of Windows XP machine (where I developed and built foo.exe) to C:\foo of Windows Server 2003 machine (where I am trying to run it).
The fourth line of the manifest file looked like this:
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.6195"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
This time I could run C:\foo\foo.exe without any issues.
Question
I was expecting that installing 'Microsoft Visual C++ 2005 SP1 Redistributable' (vcredist_x86.exe) as described in the second approach would fix it. But it didn't. Copying the DLLs and manifest files from the C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT folder of the development machine fixed it. Why was it so?
Build options
In case, it helps you to answer my question. Here is the compiler and linker options I picked up from Visual Studio project properties:
Configuration properties > C/C++ > Command Line:
/O2 /GL /D "_MBCS" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Configuration properties > Linker > Command Line:
/OUT:"C:\MixedBag\Release\Foo.exe" /NOLOGO /MANIFEST /MANIFESTFILE:"Release\Foo.exe.intermediate.manifest" /DEBUG /PDB:"c:\MixedBag\release\Foo.pdb" /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
I'll answer my own question. Comments to the question by Hans Passant and Luke helped.
I downloaded Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update and installed it on the system where I was trying to run C:\foo\foo.exe. The EXE ran fine after this.
The installer placed the CRT DLLs in C:\windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86. So, yes, 8.0.50727.6195 was the version of the CRT DLLs I was looking for as Hans Passant rightly said.
The easiest way to figure this version was by looking at the manifest file generated by Visual Studio while building my project on the development system. Mine was located at C:\Foo\Release\Foo.exe.intermediate.manifest. It had a tag like this:
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.6195'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
So, this is a clue that I needed 8.0.50727.6195 version of the DLLs. The rest was a matter of searching for the right vcredist_x86.exe which happened to be in the URL I have mentioned in the second paragraph. The page in that URL contains a link to KB2538242 which shows the version numbers of the DLLs that would be installed by the installer.
Note: As Elie has mentioned in a different answer to this question, since this is a 32-bit application, it is necessary to install vcredist_x86.exe (not vcredist_x64.exe) on the system where this application is supposed to be run irrespective of whether that system is a 32-bit Windows system or a 64-bit Windows system. Once again, the .manifest file provides this clue in the processorArchitecture attribute.
You have to install "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update" which is here: http://www.microsoft.com/en-us/download/details.aspx?id=26347
Here is how you fix this issue:
You WILL STILL Get the sidebyside errors If the application being used is 32 bit and you try running it on a 64 bit OS which has the VC_REDISTx64 installed.
Simple solution, you MUST ALSO LOAD THE VC_REDISTx86 on the 64 bit os
I had a somewhat related problem. Two development XP machines with VS2005 installed, call them A and B. I developed, built and ran on A. Then I copied the whole project to B. Built there. Tried to run and got the same error messages mentioned by SusamPal. I realized that on B's WinSxS there were the x86_Microsoft.VC80.CRT_xxx manifests (and folders) but not the corresponding x86_Microsoft.VC80.DebugCRT_xxx ones (and why?!). I tried several of the dances and incantations described by SusamPal to no avail. I solved the problem by copying the appropriate folders from the WinSxS of A to B AND the appropriate manifests from the WinSxs\Manifests.
Although my application was
developed on Win 2k8 R2 x64 with vs2008 (which has msvcm90.dll, msvcp90.dll and msvcr90.dll in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT)
and ran on win 2k3 SP2 x64,
but the msvcm80.dll, msvcp80.dll and msvcr80.dll are needed.
After install Microsoft Visual C++ 2005 SP1 Redistributable Package (x86), the application can be installed and ran rightly.
For me the side by side error went just by chabging the under the setting c/c++ ->CodeGeneration->RuntimeLibrary ,make it MTD that is multi-Thread Debug
We have really following problem here: the application executable references dlls using manifest machinery. In the deep past application authors just copied required dll's into system directories. Unfortunately this caused so called "dll hell" problem when overwriting older dll versions by incompatible newer one could make applications stop working. MS then came up with with versioning idea (winsxs).
Unfortunately this is quite complex machinery and it is definitely not a good idea to try manually installing dlls (assemblies) into the sxs folder. Installing so called "redistributable packages" is not a perfect solution either.
Additionally, this cannot help when we want debug versions. As MS prohibits distribution of debug versions of supporting dlls, "redistributable packages" won't install them. (Note that the assembly id depends on current subversion of VS2005 and is related to installed supporting libraries.)
Usually, the VS installer adds the required assemblies to the system, but after some time installation of updates or newer SDK's and tools may damage this correct state.
Let's assume we have this situation - our debug libraries are no longer integrated into system. Suppose we have given workspace with project A and active debug configuration giving not working application. We can then create installer project, say C in current workspace, add our application (or strictly, project with active configuration) to it. Setup installer project to put our executable in some place (desktop is the right place regarding this situation) enable dependencies check and some other minor properties. Then build project C and run installer (or "install" from VS using context menu). Now your application and other created with debug dll libraries start to work.
Beware when you run installer with "remove" option you came to previous situation. Here is good article related to distribution topic: http://blogs.msdn.com/b/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx.
If you have some other applications and want to deploy them simply by copying, maybe on non development machine without installed VS, you may create dummy project together with appropriate configuration and installer for it . You then install it once on each machine and then copy executable(s) you are working on.