Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.
Related
I'm trying to get the compilation args for each compilation unit so I can create the "compilation_commands.json" for my vcxproj that can be used with clang's libTooling.
The libTooling tutorial suggests using a CompilationDatabase to provide the compilation args for all the cpp files in a project. The tutorial shows that CMake can generate the compilation_commands.json for CMake based projects.
Since clang can be put into "MSVC mode" via clang.exe --driver-mode=cl or clang-cl.exe my thought was if I could get the compilation args for each cpp file in my VS2012 project I can create the compilation_commands.json for a vcxproj.
However I'm having trouble finding APIs in the VS2012 SDK that walks a vcxproj and retrieves the compilation args for each compilation unit. Can someone point me towards the right APIs?
I know this is really old, but the question is still relevant, so for those still looking for an answer, I managed to finally do this recently using this little VS extension.
Just install it and a new 'Sourcetrail' menu will appear, with a 'Create Compilation Database' entry (I found Intellisense needs to be enabled for it to be clickable). That will let you customize what to include and generate a compile_commands.json that you can use with other clang-based tools, etc.
It is a DIY job. The VS IDE projects have properties for each .cpp file. By selecting a .cpp, then right-click -> Properties -> Config properties -> C/C++ -> Command-Line you have the options required to compile that specific file. The 64 dollar question is how to do it for every file in the project / solution. The answer is not trivial, but it is doable. At least I did it on VS 2010 and I'm pretty sure it works on VS 2012/3
The secret lies with what is called VCEngine. It is a tool that evaluates all the properties or the files in the project. So the real problem is how to evaluate the property "Command Line" for each file. You need to iterate through all the .cpp files and call VCProject's Evaluate method for the "Command Line" property.
The simplest way I think you can do it is to write a plugin for the VS IDE and thus gain access to the VCEngine instance. There are plenty of examples of how to do that. Be aware that the VCEngine is version dependent.
Anywhay, for projects/solutions with thousands of .cpp files, you need to automate the compilation database creation.
When I'll have time I will put the solution on github
You may be interested in reading this
compile_commands.json for Windows/MSVC
You can try to parse the CL.command.* files in the intermediate directories.
https://gist.github.com/Trass3r/f3fbe6807d28106e917368c33abf45d4
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
I am using F# in Visual Studio 2012 and this may seem like a dumb question but I cannot figure out how to specify include directories, specifically for binaries. I see how to do it for F# interactive using the #I directive and it works there, but the #I option is not available in the non-interactive form. The compiler error message says to use the -I compiler option. I have looked under Project Properties, where the only subsections visible are Application, Build, Build Events, Debug, and Reference Paths none of which provides any obivous way to specify an include directory path. The help system isnt much help as it seems to reference sections that are unavailable.
Well i still have the problem with VS12 but at least i have a workaround, by calling the compiler from the command line. You have to use the -r option to specify the location of the dll:
fsc -r:<complete path to dll> <fname>
However when i try the corresponding step in VS (by trying to set one of the Reference Paths) it says there are no items found in the DLL folder. So perhaps someone familiar with CS can help out
I've been using Libpng15 in Windows 7, but I've been getting errors in relation to the
Unresolved External _png_set_longjmp_fn error when I compile my code. I followed the directions in the aforementioned link, and while it DID compile without any errors, I wound up with a message saying that I needed libpng12.dll to continue.
So, I did some Googling for libpng12.dll...nothing came up but generic "find x.dll" websites which appeared to be scams.
I've tried reading the INSTALL docs for the libpng source code on their website, and all that I see is instructions on how to do it via Unix based systems. I tried to do this in Cygwin with no luck, so I'm kind of stuck on how to compile this library.
All in all, I'm willing to do either the compilation or just using the .dll, though the problem is that I can't find a working .dll for version 12.
Another thing I tried was downloading binaries from here, which claimed to be "libpng12 for windows". I then copied the files into my VC compiler directory, which overrode libpng15, I think. Still, when I link against it statically and run my program in VC, it says that I require the .DLL file. The libpng12.dll file was in fact a .dll.a file instead. I honestly am not sure to link these (I tried linking it statically by typing "libpng12.dll.a" in the Linker Input setting through VS).
If I can go the .dll route for libpng12, how do I do this? Where is the file? How do I link it in VS?
Any help would be appreciated, as it seems there really isn't a whole lot of information on this. Either that, or I'm just not looking properly.
Look in the "projects" directory of the libpng distribution, and use one of the visual projects.
As mentioned above Look in the "projects" directory of the libpng distribution
Then make the adjustments outlined here
https://stackoverflow.com/a/38547948/293792
Which I note here for simplicities sake
(as stated there) adding two lib values to
Config -> Linker -> Input -> Additional Dependencies
these values are ucrt.lib;vcruntime.lib
Ensuring the build type is /MD
Allowed me to build these older versions, and fix that error on Windows 10 VS2015.
This link seems to have an installer for 1.2 for you:
http://gnuwin32.sourceforge.net/packages/libpng.htm
it's 32 bit. Not sure if that makes a difference for you.
I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.