hey all, I just installed VC 2010 Premium Beta2 on my system and I migrated my old vc9 projects to it... everything seemed ok at first...
what's strange is that no matter what I compile I get the following error message:
1> Microsoft (R) Incremental Linker Version 6.00.8447
1> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
1>
1> ■/
1>LINK : warning LNK4044: unrecognized option "ERRORREPORT:PROMPT"; ignored
1>LINK : fatal error LNK1181: cannot open input file " ■/.obj"
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
the warning about errorreport is a little annoying but non-fatal... annoying because no matter which errorreport setting I choose, the warning stays... however the LNK1181 is fatal and even more frustrating because it seems to have no detectable cause.
my input list contains no .obj files, only various .lib files... furthermore, there is that strange block-like special ascii character in the name which I've certainly never typed anywhere. initially when this showed up I thought it must be some artifact of the vc9 to vc10 migration... and after spending 2 hours looking all over for the cause, it occurred to me to test whether or not it occurs with brand new projects... well sure enough it does!!
I create a BRAND NEW project... involving no migration, nada... just a brand new win32 project with the default afx files and so forth... I don't change any default setting and it gets this exact same linker error!
I hope somebody here can shed some light because this is very mysterious... at the moment the only other diagnostic method I can think of is to try to create a new workspace and add a new project to that and see if that works... ok just tried that and no dice... problem still persists.
anybody have some advice or seen this before?
You have an old copy of your pre-processor or linker (cl.exe, link.exe) in your system path.
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 just updated from 0.8.14 to 1.0 RC4 and now my NDK support seems broken.
The failing ndk-build call:
C:\Users\layer0\AppData\Local\Android\android-ndk32-r10b-windows-x86_64\ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\Android.mk APP_PLATFORM=android-20
NDK_OUT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj NDK_LIBS_OUT=C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\lib APP_ABI=all
Error message from make:
make.exe: *** No rule to make target C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj/local/armeabi-v7a/objs/my-jni/C_\Users\layer0\AndroidStudioProjects\GameEngine\app\src\main\jni',
needed by C:\Users\layer0\AndroidStudioProjects\GameEngine\app\build\intermediates\ndk\debug\obj/local/armeabi-v7a/objs/my-jni/C_\Users\layer0\AndroidStudioProjects\GameEngine\app\src\main\jni\buffercopies.o'. Stop.
The whole project, including the JNI parts was compiling fine just hours ago before the update. I guess something changed in the configs or about the supported ABIs?
But i don't really know what to look for.
Write it down, think, try again ... find a solution. grrrr
Effect was this bug:
https://code.google.com/p/android/issues/detail?id=66937
Issue 66937: "no rule to make target" when compiling only one .c file with ndk-build.cmd launched from gradle
Once the .so files are created the dummy.c file can be removed. I did that and forgot about the bug, so it came back after the update.
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.
I just finished my project and tried building it in Release for the first time. I've had previous issues with the Windows 7 SDK and the Common7 stuff located in program files(ie they were missing and I had to install them from msdn).
The build is complaining :
1>LINK : fatal error C1350: error loading dll 'msobj110.dll': dll not found
1>Block.obj : fatal error LNK1000: unknown error at 00A14372; consult documentation for technical support options
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Yet I looked at :
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE
I have the same folder under C:\Program Files..., and IDE is almost empty; doesn't have the ms libraries.
How can I know where Visual Studio picks these dll from? I'm using VS2012.
i am using GLUT 3.7.6 with VC++6.0 n on compiling a program i get following error
--------------------Configuration: abc2 - Win32 Debug--------------------
Linking...
LINK : fatal error LNK1104: cannot open file "abc2.exe"
Error executing link.exe.
abc2.exe - 1 error(s), 0 warning(s)
i have included all the header files ...linked all the lib files bt still the result is same...!!...please guide me through this problem...THNX in advance...!!
This usually happens when the output file already exists and something has a lock on it. Check to see if abc2.exe is alright running, or of some program has a file lock on it.
You can check whether abc.exe is running using Process Explorer from sysinternals. If that's the case the link step will fail.
Also check the target file is not write-protected.
All the Microsoft tool error codes are documented online - see here for more reasons why you might see LNK1104.