I am building an universal windows app in c++, in which I'm using librtmp. I worked through a load of error messages, but I can't solve one of them:
LINK : fatal error LNK1181: cannot open input file 'C:\OpenSSL-Win64\lib.obj'
I did a ctrl+shift+f on the entire project, and I couldn't find a reference to lib.obj anywhere, so I don't know where this file is linked in. I checked if the additional dependencies were set correctly, without quotation marks, which was the case.
I also tried running the linking process with the /verbose flag, but that didn't return any useful information:
1>
1> Starting pass 1
1>LINK : fatal error LNK1181: cannot open input file 'C:\OpenSSL-Win64\lib.obj'
Does anyone have an idea how to solve this problem, or any pointers on how to diagnose the linking process better?
The vc++ linker is quite verbose when the /verbose switch is turned on. From what you get as a response, it hasn't even started to search libraries for the obj. This means that the obj file is part of the input, directly on the linkers command line.
Check the "CommandLine" properties for the given obj (Maybe it sneaks in there in the form of some kind of macro?). Also, make sure you are not inheriting some "Additional dependencies" from another configuration. Also, make sure you checked the "Additional dependencies" for the configuration/platform set that you are building.
Also, under Tools -> Options -> Projects and Solutions -> Build and Run, turn up the verbosity of the msbuild output. This way you also get the actuall commands passed to the various tools. (This is basically the content from the response files.) The obj you are looking for must end up in that somehow and turning up the verbosity should give you a handle to find out where it's actually coming from.
Related
I have installed the latest version of fltk 1.3.3. I run into build errors every time I want to build the "Demo" project in VS 2015. I have seen the same question for older versions of VS; none of them seem to help me resolve this issue. I've tried to change the debug information format to the other available values but this has not helped. In fact when I tried to build a release version, avast kicked in and blocked the whole thing. When it comes to dealing with the $(OutDir), $(TargetName) and $(TargetExt) property values, I'm totally out of my depth. This takes me to Microsoft.CppBuild.targets which is something I don't want to mess with. FLTK is SUCH a pain to do anything with from beginning to end. This is the message I get:
"MSB8012 TargetPath(C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\ide\VisualC6.\Debug/Demo\Demo.exe) does not match the Linker's OutputFile property value (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\test\Demod.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). Demo C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets 1189"
If there's anyone out there with some ideas as to how to resolve this, I'd greatly appreciate that. I've spent the whole day trying to figure this out.
It looks like the target specified by the linker (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\test\Demod.exe) is different than the target specified by the compiler (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\ide\VisualC6.\Debug/Demo\Demo.exe).
If you right click on your project > Properties > Configuration Properties > General
Make sure that "Output Directory" and "Target Name" match Configuration Properties > Linker > Output File.
You could make them the same by setting Linker > General > Output File to
$(OutDir)$(TargetName)$(TargetExt)
If your Linker's output file is already set to that, then the macros are somehow wrong.
I would like to disable the linker for a particular project configuration of a VS2013 C++ project. How can I do this?
I have tried to remove the output path, remove the <Link> parts of the project file, but this only results in error messages ("error : The OutputPath property is not set for project" / "error: The output paths do not match" etc.)
The reason is that this particular configuration does preprocessing to file so no object files are created, which always results in a linker error.
There is a compiler switch /c to "compile only". Unfortunately this is only available outside of Visual Studio. So you would need to build the project on the command line using cl.exe.
I came across AntTweakBar Fraemwork and was very impressed.So i thought of integrating it to my program as well.
I add the include directory to the include path in the project properties
I also added the path to the lib in the library directory in project..
Even after adding AntTweakBar.lib to the input Linker..
I keep getting this error while debugging
*The Program cannot start as AntTweakBar.dll is missing from the computer *
I dont know what to do...
Please do help me out here
Plaese....
Waiting eagerly for an answer.
Thanks in advance
You may need to extend the PATH environment variable with the directory where that AntTweakBar.dll file is actually installed.
The error message you get indicates, that the dynamic linker isn't able to find and load it when your program starts.
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
EDIT: See my answer below for the hotfix.
ORIGINAL QUESTION:
In setting up for our boat-programming adventure I have to set up source control and fix project files for a team to use them. (the project was previously only being worked on by one person who took shortcuts with setting up the project includes, etc)
I am fixing those SLN and Proj files. When trying to do a build on an external USB drive (I have not tried it on the primary hard drive) I am getting odd errors (lots of them for various files):
fatal error C1083: Cannot open
compiler generated file:
'.\Debug\.sbr': Permission
denied
These files are referenced in the vcproj file with relative paths in double quotes:
RelativePath="..\..\Source\.cpp"
I get the same errors form within a sln file in the IDE or if I call msbuild with the sln file.
The files are kind of "shared" for a few sln files (projects).
The person who originally created the SLN files is not known for being a wizard at configuring MSDev or making things work for teams.
Is this an issue with the way the source files are referenced? Any suggestions on how to fix these?
This URL does not seem to have helpful information:
Fatal Error C1083 on MSDN
Note - there were/are still hardcoded paths in the proj file, but i don;t see them for these files. They were mostly for the include and lib dirs. I think I removed them all.
I also get these errors:
..\..\Source\.cpp : error C2471:
cannot update program database '\debug\vc90.pdb'
..\..\Source\.cpp(336) : fatal
error C1903: unable to recover from
previous error(s); stopping
compilation
..\..\Source\.cpp(336) : error
C2418: cannot delete browser file:
.\Debug\.sbr
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
Symptoms:
D8022 : Cannot open 'RSP00000215921192.rsp'
PRJ0008 : Could not delete file 'vc90.idb'.
C1083 : Cannot open program database file 'vc90.pdb'
C2471 : Cannot update program database 'vc90.pdb'
LNK1103 : debugging information corrupt.
Cause:
This problem occurs when all of the following conditions are true:
You have a solution with more than one project in it.
Two or more of the projects are not dependent on each other.
You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
You are building on a system with multiple CPUs (cores).
Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
A specific race condition in mspdbsrv.exe remains uncorrected.
Resolution:
To resolve the problem do one or more of the following:
Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
Disable parallel builds.
Add the "/onecpu" boot option to your boot.ini file.
Change you BIOS settings to enable/use only one CPU.
File a problem report with Microsoft Technical Support and keep bugging the crap out of them until they eventually fix mspdbsrv.
Status:
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
Applies to:
Microsoft Visual C++ 2005
Microsoft Visual C++ 2008
Others?
Respectfully submitted:
"Fish" (David B. Trout)
fish#infidels.org
p.s:
You're welcome. :)
Hmmm.
Perhaps:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/
there is a hotfix from MS
http://code.msdn.microsoft.com/KB946040
http://support.microsoft.com/kb/946040
That might be my problem. I think it might only be on one machine I have.
EDIT:
I downloaded and ran the hotfix installer. It seems to have fixed it.
I get this same error when I physically remove a file from disk, but leave it in VS. In VS2005 it would give a much better : fatal error file not found. I think this is a bug in VS2008. The hotfix mentioned above didn't help me.
In my case it was my virus package (Trend Micro) causing all the problems. I added my Dev folders to the Ignore/White lists to solve the problem
delete your debug folder and build your project agian.
Occastionally my Visual Studio will suddenly decide something like this. I have found it maybe help to toggle to release, do a full rebuild, then toggle back to debug.