I'm trying to compile an install shield project. It's a 64 bit program.
I keep getting this error, although it does compile OK and installs OK:
Error 16 -6058: Error merging Visual C++ 10.0 CRT (IA64) with module ID C:\Program Files (x86)\Common Files\Merge Modules\Microsoft_VC100_CRT_ia64.msm ISEXP : error : -6058: Error merging Visual C++ 10.0 CRT (IA64) with module ID C:\Program Files (x86)\Common Files\Merge Modules\Microsoft_VC100_CRT_ia64.msm
Any idea how can tell it NOT to try and merge ? (I can let it install the CRT ad a redistributable instead)
Ok, so it's like this:
Was detected as a dependency by mistake:
Adding merge module 'Visual C++ 10.0
CRT (IA64)' that is a dependency of
component
'MyProjectName.Primary_output'
So you go to:
Specify application Data -> Files
Right click on the specified project that had the dependency.
Choose Dependencies from scan at build.. find that unwanted file, and uncheck it.
Some Installshield products (2010, 2011 at least) appear to have an issue scanning managed (/clr) c++ modules that use the 10.0 CRT, even for 32-bit-only projects. In those cases the IA64 msm gets added to the project, producing "error -5008: Intel64 or AMD64 must be specified in the template of the Summary Stream". Yochai's fix cured that too. I have not seen this issue for native c++ code.
Related
I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3
I am trying to run a simple program through cmake gui and I receive the following output. I am not really sure what the problem is and forgive me, because I am quite new to this. I have also uninstalled and installed visual studio 2012 and 2013 to see if that would make a difference. I am using Visual Studio 2013 as the compiler and get the following configuration error.
My environment is :
Windows 7 enterprise 64 bit
Cmake gui 2.8.12.2
Visual Studio 2013 Professional
The C compiler identification is MSVC 18.0.21005.1
The CXX compiler identification is MSVC 18.0.21005.1
Check for working C compiler using: Visual Studio 12
Check for working C compiler using: Visual Studio 12 -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/cl.exe" is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/PM&R/Desktop/CMakeFiles/CMakeTmp
Run Build Command:C:\PROGRA~2\MSBuild\12.0\Bin\MSBuild.exe
cmTryCompileExec3676669247.vcxproj /p:Configuration=Debug
/p:VisualStudioVersion=12.0
Microsoft (R) Build Engine version 12.0.21005.1
[Microsoft .NET Framework, version 4.0.30319.18444]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 3/31/2014 2:27:43 PM.
Project
"C:\Users\PM&R\Desktop\CMakeFiles\CMakeTmp\cmTryCompileExec3676669247.vcxproj"
on node 1 (default targets).
C:\Users\PM&R\Desktop\CMakeFiles\CMakeTmp\cmTryCompileExec3676669247.vcxproj(60,85):
error MSB4025: The project file could not be loaded. An error occurred
while parsing EntityName. Line 60, position 85.
Done Building Project
"C:\Users\PM&R\Desktop\CMakeFiles\CMakeTmp\cmTryCompileExec3676669247.vcxproj"
(default targets) -- FAILED.
Build FAILED.
"C:\Users\PM&R\Desktop\CMakeFiles\CMakeTmp\cmTryCompileExec3676669247.vcxproj"
(default target) (1) ->
C:\Users\PM&R\Desktop\CMakeFiles\CMakeTmp\cmTryCompileExec3676669247.vcxproj(60,85): error MSB4025: The project file could not be loaded. An error occurred while parsing EntityName. Line 60, position 85.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.02
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
Configuring incomplete, errors occurred!
See also "C:/Users/PM&R/Desktop/CMakeFiles/CMakeOutput.log".
See also "C:/Users/PM&R/Desktop/CMakeFiles/CMakeError.log".
Try to generate build system in the folder C:/Tmp to test if the problem is related to corrupted cache or path issues. To build it to the folder stated in the question:
Check that you do have write permission in "PM&R" personal folders
Remove cmake cache when you change the generator
I have a C source file to build 32 and 64 bit binaries and it builds fine with Visual Studio 2005. When I try to build the same with VS2012 on Windows 2008 Server I get the below Link error. While the 32 bit builds fine, the 64 bit is fails.
I do not have a VS project to build this source instead I use a makefile to build.
msvcrt.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetTickCount64 referenced in function __security_init_cookie
I have searched and found lot of hits but none seem to help me as the solution/workaround given are for projects created using VS IDE.
I have defined -DWINVER=0x0600 -D_WIN32_WINNT=0x0600
Can someone help please?
Got it resolved. Wrong version of Kernel32.lib was being picked for 64 bit build. It was from an older version of MSSDK. Updated the LIB path to insert C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x64 helped to resolve the issue. Thanks every one.
I just downloaded OpenNI 2 SDK (www.openni.org) and I am trying to setup a project in Visual Studio 2012.
What I did:
Create a new C++ Win32 Console Application Project
Go to Project>MyProject Properties and, in Configuration Properties>VC++ Directories...
Added C:\Program Files (x86)\OpenNI2\Redist\; to Executable Directories
Added C:\Program Files (x86)\OpenNI2\Include\; to Include Directories
Added C:\Program Files (x86)\OpenNI2\Redist\; to Reference Directories
Added C:\Program Files (x86)\OpenNI2\Lib\; to Library Directories
But when I try to build I have the following unresolved symbol error (where ConsoleApplication1 is my project's name)
Error 1 error LNK2019: unresolved external symbol
__imp__oniInitialize referenced in function
"public: static enum openni::Status __cdecl openni::OpenNI::initialize(void)"
(?initialize#OpenNI#openni##SA?AW4Status#2#XZ)
c:\Users\MyPC\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.obj
ConsoleApplication1
I know this linking error is saying that the linker can't find some libraries but I thought what I just did was enough.
I also tried the 64 bit version, creating a 64 bit project, but I have the same errors.
I couldn't find satisfying documentation on this topic.
I'm sure I'm missing something silly. Can you please give some advice on this?
Also you should do the below steps:
0-In the C/C++ section, under the "General" node, select
"Additional Include Directories"
and add
"$(OPENNI2_INCLUDE)" (if you use the 32-bit version) or
"$(OPENNI2_INCLUDE64)" (if you use the 64-bit version).
These are environment variables that point to the location of the OpenNI Include directory. (The defaults are :
C:\Program Files\OpenNI2\Include or
C:\Program Files (x86)\OpenNI2\Include)
1-In the Linker section, under the "General" node, select
"Additional Library Directories"
and add
"$(OPENNI2_LIB)" (if you use the 32-bit version) or
"$(OPENNI2_LIB64)" (if you use the 64-bit version).
These are environment variables that point to the location of the OpenNI Lib directory. (The defaults are:
C:\Program Files\OpenNI2\Lib or
C:\Program Files (x86)\OpenNI2\Lib)
2-In the Linker section, under the input node, select
"Additional Dependencies"
and add
OpenNI2.lib or OpenNI2.lib
3-Ensure that you add the Additional Include and Library directories to both your Release and Debug configurations.
4-Copy all the files from OpenNI's redist directory (see environment variable "$(OPENNI2_REDIST)" or "$(OPENNI2_REDIST64)") to your working directory. (The defaults are
C:\Program Files\OpenNI2\Redist or
C:\Program Files (x86)\OpenNI2\Redist).
Be aware that when you run from command line, the working directory is the directory where the executable can be found, and where you run from Visual Studio the default directory is where the project file (.vcproj, .vcxproj) can be found.
you also need to point to the actual library file: openni2.lib
If you add all of options (Include, Lib, ...) to your project setting and again get this error, maybe your project platform is Win32 and you want to use OpenNI x64
In this case, you must change the platform to x64 (Project properties at the top of the page)
If you don't have x64 option, make a new one ;)
I am trying to build the boost.thread library for Visual Studio 9.0. I used bjam to build the lib-files:
bjam toolset=msvc-9.0 variant=release threading=multi link=shared
The compilation succeeded and I got plenty of .lib and .dll files under boost/stage/lib.
Then I added include path and the above lib path to Visual Studio 9.0.
But when I try to compile some program, I always get the following error:
libboost_thread-vc90-mt-s-1_49.lib cannot be opened.
The lib file created by the build has slightly another name:
boost_thread-vc90-mt-1_49.lib
I tried to rename my file to match the expected name, but Visual Studio still cannot find the file.
It seems that the filename beeing seaarched depends on the project option "C/C++ / Code generation / runtime library". I need the option "Multithreaded /MT".
What am I doing wrong?
Thank you in advance.
You're trying to link statically with CRT, but dynamically - with Boost. This is not a good idea, but if you insist, you should define BOOST_ALL_DYN_LINK macro.
Better option would be to select /MD in your project options, or to set "link=static" when building boost.