I'm receiving the following build warning when attempting to compile a .sln for Chromium:
Warning 1 warning MSB8012: TargetPath(C:\chromiumtrunk\chromium\src\base\allocator\..\..\build\Debug\allocator_extension_thunks.lib) does not match the Library's OutputFile property value (C:\chromiumtrunk\chromium\src\build\Debug\lib\allocator_extension_thunks.lib). 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 %(Lib.OutputFile). C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets 1299 5 allocator_extension_thunks
It is complaining that this path:
C:\chromiumtrunk\chromium\src\base\allocator\..\..\build\Debug\allocator_extension_thunks.lib
doesn't match the expected path:
C:\chromiumtrunk\chromium\src\build\Debug\lib\allocator_extension_thunks.lib)
but... "\base\allocator..\..\" should cancel out... right? The only other difference between the two paths is the fact that the .lib gets output to a /lib folder. This seems correct. I don't understand how I should be properly resolving this message.
I'm happy to provide any information necessary. I assume it's just a simple variable tweak, but a bit lost..
C/C++ -> General -> Output Directory: '..\..\build\$(Configuration)\
C/C++ -> General -> Intemeradiate Directory: '$(OutDir)obj\$(ProjectName)\
Librarian -> General -> Output File: $(OutDir)lib\$(ProjectName).lib
Yes, the extra "lib" produces this warning, the two paths do not match. Not actually sure what goes wrong, the final .lib file does end up in the lib directory even though MSBuild reports it wrong in the build completion message. Short from that bad message, I'd guess at an issue with automatic dependencies. This friction got introduced at VS2010 when they moved from the custom VCBuild to MSBuild.
If you want to get rid of the warning then restore the library project's Output File setting to $(OutDir)$(TargetName)$(TargetExt) and change the Output Directory to ..\..\build\lib\$(Configuration).
Related
I encountered a build issue with visual studio's 'link.exe' tool, and at some point, which I would have normally investigated by passing my build command as an argument to linux's strace -efile tool to get a dump of all the files considered by the linker, which couldn't be found and which were selected. But of course, we're on Windows this time, and strace is not an option.
the problem was indeed the linker picking the wrong file when I said ntoskrnl.lib on the command line
the root cause was an invalid %LIB% contents that wasn't matching the include paths passed to cl.exe calls
Question: how could I force link.exe to reveal the full path of the files it is linking (including .lib) ? (and save myself this hassle next time)
I have a complex build I'm trying to sort out on a new build server. Using CMake for creating the makefiles. Old version of CMake on a different server was 2.8.5. New version is 2.8.12.2. For some reason, the autogenerated CMakeDirectoryInformation.cmake files are missing the CMAKE_C_INCLUDE_PATH and CMAKE_CXX_INCLUDE_PATH, which specify the absolute location of the include headers available to that particular directory. Without that information, the source code in that directory that references headers via a local path (such as foo.h versus ../../../asdf/foo.h) won't compile. Any ideas why these are missing? As far as I can tell this is supposed to be autogenerated by CMake.
I found a useful command that got me further into my build:
SET(CMAKE_INCLUDE_DIRECTORIES_BEFORE ON)
But that didn't actually solve my problem. The real issue was that in one of my CMakeLists.txt files I had:
include_directories(
$[XXXX_INCLUDE_DIR}
)
The '[' bracket was causing the build to fail because that include directory was not being used. However, on the old build server, it had no issue with this square bracket.
I upgraded Visual Studio to VS Professional 2012.
Building old Visual C++ projects resulted in the error:
LINK : fatal error LNK1158: cannot run 'mt.exe'
Putting the folder with mt.exe into the path did not help.
Currently I am using mt.exe in the folder C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\x64
Set "Generate manifest" as No in Linker. This helped
As mentioned at fatal error LNK1158: cannot run 'mt.exe', there are times where turning off manifest generation is not an option, because one is actually using manifests.
At which point, one comes back to fixing the actual problem.
One cause of the actual problem is a bad executable search path.
I personally once had a setting for $(ExecutablePath) in the project file (VC++ Directories → Executable directories in the project settings) that was yielding an executable search path one of whose pathnames wasn't a valid directory name.
The pathname had a colon in one of its directory name components (caused by prefixing ..\..\ to another variable, which happened to contain an absolute pathname with a drive letter, rather than a relative pathname as expected).
In a sensible world, errors in path searches caused by merely bad/missing directories cause the pathname to just get skipped over, and the search to proceed to the next pathname in the search path.
link, in contrast, fails with this error (as indeed does midl when it tries to find cl.exe).
This is very confusing when one looks at the search path (with the build output level set to "detailed") and sees that the SDK directory containing mt.exe is right there in it, plain as day.
It seems that link does not live in a sensible world. ☺
The fix was to correct the bad project setting, of course.
An earlier attempt to compile ICU for Windows using MSVC and Cygwin worked fine. This time, however, after a successful
.../icu/source/runConfigureICU Cygwin/MSVC
make ends with the following error:
.../icu/source/stubdata/stubdata.c(20) : fatal error C1083: Cannot
open include file: 'unicode/utypes.h': No such file or directory
No problems with the non-MSVC Cygwin version. I am in a different directory, but it seems that this worked before.
Update. I must have compiled it in the icu/source directory before. I went back and did runConfigureICU in-place and did not see the error. I feel sad that I have to ruin my pristine icu folder, but perhaps there is no other way to compile Cygwin/MSVC. It might have something to do with how the Microsoft compiler handles paths.
Update2. making it in icu/source makes the other location work.
The answer to this is that runConfigureICU can only be called for Cygwin/MSVC in the icu/sources directory, otherwise, cl cannot get to the cygwin-based include path.
I have a VC++ project. When i compile the project in VS2008 i get the following linker error:
**Error 1 fatal error LNK1104: cannot open file 'ATL9ProPS.def' **
I have been compiling this same code since a year (with minor changes here and there) now but never saw this error. Also, my project does not refer to any file by name 'ATL9ProPS.def. (I guess this file is part of a project that is save to computer during Visual studio installation)
When i searched for this .def file in my machine i found it in the following location
C:\Documents and Settings\Abi\My Documents\Visual Studio 2008\Projects\ATL9Pro.
But how on earth is this file bothering my project. I have no clue how this is linked to my project. Please help me resolve this.
For details
Project -> Properties -> Configuration Properties -> Linker -> Input
-> Module Definition File -> Replace this with the right def file.
Try my moving that file to a different location or by renaming the file. Also see if there is any path in the Linker -> Additional include directories refers to My Documents/.../Projects folder.
Anand,
Thanks for the response. Not exactly Linker -> Additional include directories but The Linker->ModuleDefenitionFile option was referring to the file name ''ATL9ProPS.def'. I just replaced this with the right def file and it worked. Thanks