this is my first time using visual studio after reinstall windows and stuff which happened around a year ago, and whenever i tryto compile, i get this error,
1>------ Build started: Project: TrainerBasic, Configuration: Debug Win32 ------
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
1>CVTRES : fatal error CVT1101: cannot open 'C:\Users\gamz\AppData\Local\Temp\lnk{E3BAB312-249D-4367-A832-80B6F6B34AFB}.tmp' for reading
1>Done building project "BasicProgram.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So, i don't have an antivirus software, my hardware is not full, i tried cleaning the solution.. i don't know what could be the problem... and i really want to get back to visual studio, as any other online compilers don't have windows.h for example. I ALSO TRIED TO USE THE REPAIR FUNCTION IN VISUAL STUDIO. P.S. I am using visual studio community 2019
Linker Tools Error LNK1123:
Input files must have the Common Object File Format (COFF) format. If
an input file is not COFF, the linker automatically tries to convert
32-bit OMF objects to COFF, or runs CVTRES.EXE to convert resource
files. This message indicates that the linker could not convert the
file. This can also occur when using an incompatible version of
CVTRES.EXE from another installation of Visual Studio, the Windows
Development Kit, or .NET Framework.
I suggest you could follow the following methods to fix the issue:
1,Try building with incremental linking disabled.Property->Linker. Change the value of Enable Incremental Linking to No.
2,Try turning off the Embed Manifest option.Property-> Manifest Tool->Input and Output. Change the value of Embed Manifest to No.
3,Verify that the version of CVTRES.EXE found first in your PATH environment variable matches the version of the build tools, or the version of the Platform Toolset, used by your project.
For more details I suggest you could refer to the Doc:https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk1123?view=vs-2019
According to the Doc
The Visual Studio compilers and build tools can report many kinds of
errors and warnings. After an error or warning is found, the build
tools may make assumptions about code intent and attempt to continue,
so that more issues can be reported at the same time. If the tools
make the wrong assumption, later errors or warnings may not apply to
your project. When you correct issues in your project, always start
with the first error or warning that's reported, and rebuild often.
One fix may make many subsequent errors go away.
As far as I'm concerned, after you fix link1123 error, CVTRES errors and warnings may go away.
Related
I'm using VS2019 to build 32-bit release.
1>------ Build started: Project: modulesLib, Configuration: Release Win32 ------
1> Creating library ..\..\GeneratedFiles\Release32\\modulesLib.lib and object ..\..\GeneratedFiles\Release32\\modulesLib.exp
1>Generating code
1>Previous IOBJ not found, fall back to full compilation.
1>\modules\stdafx.h.cpp : fatal error C1083: Cannot open compiler intermediate file: '..\..\GeneratedFiles\Release32\\modulesLib.ipdb': Not enough space
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "modulesLib.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 8 up-to-date, 0 skipped ==========
I already found that removing /GL option temporary solved it but this is not the solution.
I have a lot of free space on system drive as same as drive where compilation occurs. I have 32GB RAM, 64-bit Win10.
Is there any solution? Thanks
Edit: Based on the next observations although C1083 is compiler error the reason is that 32-bit linker is running out of memory (reaches 3GB and than process crashed). I believe I saw somewhere that it's possible to use 64-bit toolset to generate 32-bit apps. But I can't find it now.
Ok, I just solved it.
It's a caused by 32-bit linker (although Cxxx error is compiler error).
I obviously reached 3GB limit for /GL (Whole Program Optimization) switch.
The solution is to tell VS to use 64-bit tools to compile 32-bit app via "Prefered build Tool Architecture" set to 64-bit
The same option can also be set via command line (for MSBuild) or via editing vcxproj: https://learn.microsoft.com/en-us/cpp/build/walkthrough-using-msbuild-to-create-a-visual-cpp-project?view=vs-2019#using-msbuild-with-the-64-bit-compiler-and-tools
I have several Visual C++ projects (.vcxproj) that we have in a Visual Studio 2013 Solution. From a clean code pull, everything builds successfully in either Visual Studio 2013 or a build script that calls MSBuild on each project in the proper order (a relic from the days of old, which we are working, slowly but surely, to replace).
We have a few issues with this. First, if we build from the build script first, and then try to debug, it says that most of the projects are out of date. This is annoying, but I think this is due to the batch file not touching something in the intermediate directory the same that Visual Studio does. I find similar problems documented at Stack Overflow and Microsoft Connect. Is there an alternative to modifying the Microsoft.CppBuild.targets file? I'd like to have a fix for this that doesn't involve manually modifying all of the developer's machines.
The primary problem is: If we build a project from within Visual Studio 2013, it will build and link successfully. However, if we then go and build the same project from the build script, we get:
OtherProject.lib(SomeObject.obj) : error LNK2011: precompiled object not linked in; image may not run [Full path to .vcxproj]
OutputFile.dll : fatal error LNK1120: 1 unresolved externals [full path to .vcxproj]
Does anyone have tips on how to figure out which precompiled object this is as well as why the Visual Studio based build could manage to figure things out? Do I need to review every library dependency, and each of their dependencies? Is there an easier/automated way to do this? One thing to note is that Visual Studio 2013 does not always get it right and fails with the same warning.
Our batch file build command is:
msbuild /nologo /maxcpucount /clp:NoSummary /p:BuildProjectReferences=false /p:Configuration=Debug /verbosity:normal ProjectDir\Project.vcxproj
I ran into this problem recently (few days ago everything was working fine): Visual Studio 2012 started to refuse to build native WP8 projects.
Today, I created new solution from template 'Windows Phone Direct3D App (Native Only)' to check if my newly created DLLs will be properly supported on WP. I tried to compile this project, first without any changes or additional references - pure code generated by VS. However, it failed with given error.
I know very well what does it mean and what could be the possible reason, but I can't understand, hovewer, where does it come from in this case.
Weird thing: this only happens in 'Win32' configuration, ARM compiles fine:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug ARM ------
.......
Build Summary
-------------
00:11.742 - Success - Debug ARM - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
but Win32 does not:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug Win32 ------
.......
1>LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
Build Summary
-------------
00:09.725 - Failed - Debug Win32 - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
My standard (native C++/Win32) projects also work as expected (in both Win32 and x64 platform targets).
Project configuration: (in both platforms)
Linker::Input:
d3d11.lib;%(AdditionalDependencies)
Linker::Ignore:
ole32.lib;%(IgnoreSpecificDefaultLibraries)
VC++ Directories:
Microsoft.ARM.Cpp.User:
$(WP80ToolSetPath)lib\arm;$(WindowsSDK_LibraryPath_ARM);
Microsoft.Win32.Cpp.User:
$(VCInstallDir)lib;$(VCInstallDir)atlmfc\lib;$(WP80ToolSetPath)lib\x86;$(WindowsSDK_LibraryPath_x86)
Any ideas what else could be wrong or configured incorrectly? I'm running out of ideas, I have never seen something like this before.
By the way, I have noticed one more change: when I was trying to compile WP8 projects in ARM configurtion before, there was always an error, saying "building ARM application on desktop is not supported" (or something like that). Now ARM compiles with no problem. Is it normal?
Finally, I have found the reason of my problems: as I suspected, internal Visual Studio configuration has been broken.
I did all standard steps, that can be performed in case of LNK1104, however:
- kernel32.lib was in valid location
- all include and library directories was correct
- standard *.props files were attached to each project
However, the cause was lying elsewhere.
All paths are defined using standard macros. One of them is $(WindowsSDK80Path), which is used to build include/library paths. On my system, this macro was defined as
C:\Program Files (x86)\Windows Phone Kits\8.0
instead of
C:\Program Files (x86)\Windows Kits\8.0
And that's it. I do not know, when or how, this problem arosed. Visual Studio repair via orginal installer was sufficient method to fix everything. All projects compile now without any problems.
Our team is migrating whole baseline from VS2008 to VS2012. There're over 400 C++ projects. There're 6 C++ project show wired error, such as :
1>------ Rebuild All started: Project: SSLT, Configuration: Release Win32 ------
1> stdafx.cpp
1> ???
1>c1xx : fatal error C1083: Cannot open source file: '???': No such file or directory
1> ??????????????????????????????
1>c1xx : fatal error C1083: Cannot open source file: '??????????????????????????????': No such file or directory
All files which are the parameters of cl.exe seems in wrong encoding, and cl.exe can't find them.
Firstly, i think it must be encode issues of .vcxproj, so i save as other encoding style. But still happens.
Then i re-upgrade these projects with such issue, but always build error.
At last, I change the project platform toolset back to VS2008, then build pass. So i think it's not because project file encode format. I don't know what wrong with them when using 2012 compiler. These projects build no error using 2008 compiler. And as i know from VS2010, project format changed a lot, so i can't find any clue.
Btw, there's another reason cause such issue. After upgrade, there's one property in *.vcxproj file made an unproper line break, such as:
/Zm300
/bigobj %(AdditionalOptions)
if i change it back to:
/Zm300 /bigobj %(AdditionalOptions)
Then works well, build pass.
The projects which has such issue, 80% of them are because of such issue.
Create a new sample project to see which encoding the VS expects and then convert your files to it.
Alternatively, How to: Upgrade Visual C++ Projects to Visual Studio 2012 says that you must upgrade a VS2008 project upon opening it in VS2012.
I don't have a VS2012 installation to check this, but there may be a function to convert a project programmatically in one of its DLLs - try searching with a dumpbin-based script or by examining stack traces with procmon while converting a sample project.
Thanks for your reply, i automatically upgrade our projects using: devenv.exe /upgrade *.vcproj in script.
Today i find the root cause is precompile header file: stdafx.h.
It is because that wrong precompiling head file reference. It will cause mess file name issue.
Normally, when I use Visual Studio to do a build, I see warnings and errors shown in the output pane, e.g.
1>------ Build started: Project: pdcuda, Configuration: Release x64 ------
Compiling...
foo.cpp
Linking...
foo.obj : error LNK2001: unresolved external symbol "foo"
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I'm doing some GPU programming with CUDA. Upon upgrading to 2.1, I no longer get any useful output in Visual Studio. For example, all I now see is:
1>------ Build started: Project: pdcuda, Configuration: Release x64 ------
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
The other details can be found in BuildLog.htm, but it's inconvenient to hunt that file down all the time.
Does anyone know how to force Visual Studio to show the output in its output pane?
Things that don't help:
uninstalling CUDA: the problem persists in all projects
Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity: changing this pulldown, even to "Diagnostic" has no discernable effect.
EDIT: Additional things that don't help:
devenv.exe /resetsettings
devenv.exe /resetuserdata
UPDATE (in response to Die in Sente): It's now working on one of the two machines (I'm not sure what I did to fix it though). The machine that's still having problems has a CUDA Visual Studio Wizard installed that has caused similar problems before. The still-broken machine had version 15.00.21022.8 of the compiler. The working machine has 15.00.30729.1. After making a backup, I transferred "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64" from the working to the broken machine. I observe no changes in behavior on the broken machine.
I have exactly the same problem, but without CUDA. Today Visual Studio just decided it wasn't going to show any build messages anymore. It was working fine, then one of my builds it just stopped working. The problem persists over all my projects now, and persists over reboots. I also see the correct messages in buildlog.htm. This is ridonkulous!
EDIT: Ooh, I used the add/remove programs to do a repair, and now it works again! Yeah!
did you tried to reset IDE
devenv.exe /resetsettings
or
devenv.exe /resetuserdata
I also recently install CUDA 2.1 (on top of 2.0 I believe). The default installation for CUDA 2.1 moved the SDK from
C:\Program Files\NVIDIA Corporation\NVIDIA CUDA SDK\
to
C:\Documents and Settings\All Users\Application Data\NVIDIA Corportation\NVIDIA CUDA SDK\
which initially caused me some problems. Are all of your paths resolving correctly?
This might sound like a far out suggestion. Get the CUDA SDK and try your code with the sample CUDA-C++ project in there. Maybe something changed in the build rules for CUDA v2.1.
If you go to Tools->Options->Projects and Solutions->Build and Run. Last property is "MSBuild Project build output verbosity". It defaults to Minimal, change it to normal and the build messages will show up in Output window.
This also enables any <Message Text="test message"></Message> output to show up in Visual Studio Build Output Window.
Final solution: reinstall the OS.