I am trying to build itk, however when I try to use sample programs I get the following error:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(2761): warning C4996: 'std::_Fill_n': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
2> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(2747) : see declaration of 'std::_Fill_n'
or an error like this:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(2176): warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
2> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(2157) : see declaration of 'std::_Copy_impl'
2> c:\users\ayelet\downloads\insighttoolkit-4.8.0\modules\core\common\include\itkImportImageContainer.hxx(72) : see reference to function template instantiation '_OutIt std::copy(_InIt,_InIt,_OutIt)' being compiled
basically there seems to be a problem with checked iterators.I lloked up what checked iterators are and eventually got to this link:https://msdn.microsoft.com/en-us/library/hh697468(v=vs.110).aspx.
I tried using define ITERATOR_DEBUG_LEVEL in the actual programs but that didn't help.
I tried compiling the itk libraries with ITERATOR_DEBUG_LEVEL=2 and the sample program. To do this I wrote /D_ITERATOR_DEBUG_LEVEL=2 in cmake_cxx_flags and cmake_c_flags in the cmake-gui. I am still getting the same error.
I thought of trying to stick _ITERATOR_DEBUG_LEVEL somewhere in the itk cmakelists but the whole structure seems so complex so I wouldn't know where to put it.
I'm not sure if my syntax in cmake-gui is correct because I couldn't find a single example of setting an option to a specific value in cmake-gui so I don't know if "=" is the correct syntax.(I could only find setting options - like /DWIN32) Than again there could be something else that I'm doing wrong - I just don't know.
Anyone have an idea of what I can do?
Often this kind of messages come from mixing up Release/Debug libraries and executables and it's not necessary to set the _ITERATOR_DEBUG_LEVEL manually.
I suppose you built ITK both in Debug and Release version (by selecting the drop-down in the Visual Studio menu).
Is it possible that you installed both the version in the same folder? In this case the second one has overwritten the first one (unfortunately the ITK debug libraries don't have the a _d suffix in the name , they have to be in a different folders from the release libraries).
In your sample program, when you run cmake and you are asked for itk directory, put the itk build directory (instead of the install directory).
To be really sure of what is going on, you can temporarily move the folder with the version you don't want to be included.
Related
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 am compiling several C++ sources using cl.exe (Visual Studio 2010 Express). The sources are compiling fine and it generates the respective obj files, but after the last line of "Generating code..." it throws the infamous LNK1104 error, but of the weirdest kind I have ever seen:
Generating Code...
LINK : fatal error LNK1104: cannot open file 'Color.exe'
Now, Color.exe does not exist, I do not want it to exist, I am not telling cl to create it, neither do I even tell it to link at all, I only want to compile. Color.obj happens to be the first output file of the compiler (alphabetical order), so I assume this problem is kinda linked to it.
The command line of my cl.exe invocation looks like follows (I trimmed the includes, they aren't part of the problem):
cl /nologo /Ox /EHsc /I[...] "D:\Projects\Java\JSFML\src\cpp\Intercom\*.cpp" "D:\Projects\Java\JSFML\src\cpp\JNI\*.cpp" /FoD:\Projects\Java\JSFML\out\obj\
The working directory is the MS Visual Studio directory. I assume that it cannot "open" Color.exe because it cannot write in that directory. However, my question is: why would cl even want to create it? I'm not telling it to link?
The default of most (if not all) C/C++ compilers is to perform the linking step unless you explicitly tell them not to.
If you take a look at this page which covers "cl.exe", you'll find an option, /c (compile only, no link) that will turn that behavior off for you.
You are telling it to link. If you don't want to link, use the /c option (for compile-only).
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.
To get from C++ sourcecode to a binary module, the process is roughly as follows:
set_of_source_files[a.cpp, b.cpp, ...] // conceptually, it doesn't matter where these are
||
|| Compiler <- [compiler_settings]
\/
set_of_object_files
||
|| Linker <- [linker_settings]
\/
binary module (dynamic library or executable)
Now, I know Visual Studio projects, they
Define a set of source files (directory structure and layout basically doesn't matter / is defined inside the project file)
Define the compiler settings for all (optionally each) of the source files
Define the linker settings
Define where to put generated output files
I don't know cmake, but apparently(?), the info one configures with cmake differs slightly from the info one puts into vc[x]proj files.
Is a "cmake configuration" just a differently formatted "vcproj file" or is there a conceptual difference? (Except for the obvious one (I assume) that the info I put into a cmake configuration is platform independent.)
An alternative twist to this question would be to answer -- in the context of above -- why/if(?) one would switch to cmake when only compiling for Windows with Visual-C++.
Cmake is a cross-platform make -- it starts from a set of source files and a relatively abstract set of directions about what to do with them. Based on those, it generates a set of platform-specific files. If you specify Windows/Visual Studio as the target, it can/will generate a vx[x]proj file for you to use.
Even if you're only using Visual C++ on Windows, it's possible you could benefit from cmake. The obvious possibility would be if you want to target a number of different versions of Visual Studio, and be able to directly generate the correct files for each, instead of generating files for the oldest version you want to support, and then depend on Visual Studio's upgrade feature to convert those to the target version.
Based on my experience with VS's upgrade capability (not particularly great), I'd say that could/would be a reasonable and valid use.