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.
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'm trying to create the Facebook DLL with following bindings: https://github.com/mono/monotouch-bindings/tree/master/facebook
When I use "make", I'm getting following errors:
error: invalid deployment target '5.0.0' for architecture 'arm64' (requires
'7.0.0' or later)
And
** BUILD FAILED **
The following build commands failed: ProcessPCH
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/com.apple.DeveloperTools/5.0-5A1413/Xcode/SharedPrecompiledHeaders/facebook_ios_sdk_Prefix-eeghlwplbbpvmudycetfsuytcqmf/facebook_ios_sdk_Prefix.pch.pch
facebook_ios_sdk_Prefix.pch normal arm64 objective-c
com.apple.compilers.llvm.clang.1_0.compiler (1 failure) make[1]: *
[libFacebook-arm64.a] Error 65 make: * [build-binding] Error 2
Any ideas?
Ok, finally found the answer myself and posting it here in case others have the same problem.
The make file downloads the Facebook Obj C project automatically
The "BASE SDK" of this project is set to iOS7, the 64bit deployment targets are also set to iOS7, the 32bit deployment targets are set to iOS5
It then builds the Monotouch DLL with the binding project
This targets 64bit, which is not supported on iOS5
So basically, the "make" will not work. You first need to change all deployments targets in the project to iOS7. See screenshot below.
Probably there is a better solution that also supports earlier versions then iOS7, because the Obj C project is using different targets for 32bit (iOS5) and 64bit (iOS7) and my solution now only targets iOS7.
My application is giving me a linking error when I try to build it.
Error 5 error LNK2001: unresolved external symbol "int __cdecl _AfxInitManaged(void)" (?_AfxInitManaged##YAHXZ) mfcs80ud.lib
I am building the application using Visual studio 2005. I am also linking against WINDDK for Server 2003 and Windows 6.1 SDK if this helps.
I Googled around and noticed people saying that its a precompiled header issue and it should be fixed by setting the /Yc switch in the stdafx.cpp Create/Use Precompiled header property. but that did not fix it for me and I'm not sure how to fix this.
Can someone help please.
I had same problem with Visual Studio 2010.
error LNK2001: unresolved external symbol "int __cdecl _AfxInitManaged
It turned out that was from my mistake to include another stdafx.cpp in other project.
Including more than one stdafx.cpp will produce this symptom.
Seems it solved it self once I restarted my machine.. not sure what was causing it in the first place, even restarting VS and cleaning the solution a gazillion times did not work.
Using Visual Studio 2005 to build a .NET 2003 solution, I encountered the described LNK2001 error. The project did not have a stdafx.cpp file. I added a copy of stdafx.cpp to the project and it built successfully.
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.
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.