Hi i wanted to use external library in my project so i downloaded sourcode from https://code.google.com/p/inih/ and i compiled it using Microsoft walkthrough http://msdn.microsoft.com/en-us/library/ms235627.aspx
Build started 16/01/2015 10:30:39.1>Project "c:\...\Projects\inihlib\inihlib\inihlib.vcxproj" on node 2 (Build target(s)).
1>ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /Zi /nologo /W3 /WX- /sdl /O2 /Oi /Oy- /GL /D WIN32 /D NDEBUG /D _LIB /D _UNICODE /D UNICODE /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Release\\" /Fd"Release\vc120.pdb" /Gd /TP /analyze- /errorReport:prompt ...\INIReader.cpp
INIReader.cpp
Lib: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\Lib.exe /OUT:"c:\...\Projects\inihlib\Release\inihlib.lib" /NOLOGO /LTCG Release\INIReader.obj
inihlib.vcxproj -> c:\...\Projects\inihlib\Release\inihlib.lib
1>Done Building Project "c:\...\Projects\inihlib\inihlib\inihlib.vcxproj" (Build target(s)).
Build succeeded.
Time Elapsed 00:00:00.46
It looks like inihlib.lib should be in release folder but instead ive got only inih.obj and log file. What im doing wrong any ideas?
Question was answered by Shane; issue was simply looking in the wrong folder.
You might be looking in the wrong folder, you could be looking in c:...\Projects\inihlib\inihlib\Release
instead of
c:...\Projects\inihlib\Release? – Shane Haw 1 hour ago
Just copy-pasting this for people who come looking for an accepted answer.
Related
I have a solution with two one-source-file projects in it. Each file is:
#include <mosquitto.h>
The first compiles fine. The second says it cannot find a header. The source code in the second is identical to the first, so it is a mystery why it cannot compile.
Pre-compiled headers are not being used in either, so it is curious that the /Fp option is issued, I don't see how it can be playing a role.
/permissive- /ifcOutput "x64\Release\" /GS /GL /W3 /Gy /Zc:wchar_t /I"C:\Program Files\mosquitto2.0.14\devel" /Zi /Gm- /Od /sdl /Fd"x64\Release\vc143.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /FC /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\Good.pch" /diagnostics:column
/permissive- /ifcOutput "x64\Release\" /GS /GL /W3 /Gy /Zc:wchar_t /I"C:\Program Files\mosquitto2.0.14\devel" /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc143.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /FC /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\Bad.pch" /diagnostics:column
Another user suggests posting the actual failed output.
Build started...
1>------ Build started: Project: Bad, Configuration: Debug x64 ------
1>Bad.cpp
1>T:\MyFirm\dev\MinorProjects\Bad\Bad.cpp(55,10): fatal error C1083: Cannot open include file: 'mosquitto.h': No such file or directory
1>Done building project "Bad.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I turned on Tools->Options->Projects and Solutions->Build and Run->verbosity=Detailed, and compared the CL.exe commands issued.
To my surprise, the /I include option was NOT present on the failed build command, despite being in the Properties dialog "Command Line" page as pasted above.
The issue was that I was building in Debug, but for some reason the Properties dialog was editing Release options. So, while the "Command Line" page was showing the options that would be used were I building Release, they weren't used while building Debug.
I downloaded the source code for a library that resembles the processing library but for c++ called libxd. I used CMake to generate project files for Visual Studio 2019 which worked successfully. When trying to compile the solution for all of the provided build modes, I get the following errors:
The first error invlaid numeric argument '/Wno-narrowing' is what I'm concerned about for now. I'm trying to figure out why this argument is being provided to the compiler. When looking in the properties window for the xd project in the solution I can see the command line arguments that are supposed to be provided to the compiler in the C/C++ > Command Line tab. I verified that there is no /Wno-narrowing option provided. When looking at the build output it can be seen that the option -Wno-narrowing is being provided to the compiler. Can someone help me figure out why this argument is being passed? I looked throughout the compiler properties window to see if I could see anything that would be affecting it but I can't see anything that would affect this.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe /c /IC:\dev\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
Tracking command:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\dev\libxd\build\xd.dir\Debug\xd.tlog /r C:\DEV\LIBXD\SRC\OPENSANS.CPP /b MSBuildConsole_CancelEventfa83e1bb599743cfa0c02eb67d579e28 /c "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe" /c /IC:\dev\Users\olive\Downloads\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
cl : command line error D8021: invalid numeric argument '/Wno-narrowing'
The command exited with code 2.
The error is caused because that's not a valid MSVC flag. The flag is there because the CMakeLists.txt file demands it:
set_source_files_properties(src/opensans.cpp PROPERTIES COMPILE_FLAGS -Wno-narrowing)
That project specifies what it supports for building under Windows and it's not MSVC.
Windows Prerequisites: mingw-w64 version >= 4.8.1
So you either need to build it in the supported way, or modify the build scripts to allow for MSVC.
That would entail figuring out what the flag does in gcc (disables diagnostic messages about narrowing issues) and finding the equivalent in MSVC, probably a /disable:nnnn variant, once you figure out the nnnn. Figuring that out should be relatively painless since MSVC will tell you that when you compile it - lots of Cnnnn - something to do with narrowing warning messages.
Or you could just disable the line that adds the flag (for MSVC builds only) and see if it still builds. Of course, in the spirit of open source, you should then notify the author what it took to get it going, they may be happy to support MSVC if the effort is not too high.
I have a small test project that I want to build with TeamCity. In TeamCity I have created a build step with runner type 'Visual Studio' solution. The problem is it is not building. The error I get is:
error C1069: cannot read compiler command line
Here a part of the build log:
[16:55:05]ClCompile
[16:55:05]CL
[16:55:05]C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /ZI /nologo /W3 /WX- /sdl /Od /Oy- /D WIN32 /D _DEBUG /D _LIB /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug\\" /Fd"Debug\vc120.pdb" /Gd /TP /analyze- /errorReport:queue UnitTest.cpp
[16:55:05]UnitTest.cpp
[16:55:05]c:\data\teamcity buildagent\work\d8c46b39964cb4dc\testlibrary\unittest.cpp(27, 0): error C1069: cannot read compiler command line
Try removing the space in the TeamCity build agent path:
c:\data**teamcity buildagent**\work\d8c46b39964cb4dc\testlibrary\unittest.cpp
There is a bug with the VS2013 compiler as documented here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/82304c15-37e2-4761-8928-0c67e074bf47/error-c1069-cannot-read-compiler-command-line-on-visual-studio-2013-rc?forum=vcgeneral
(Note, this is referring to the RC and could now be fixed)
I am building glm for vs 2012 but I get these errors with cmake
when I run vs2012 and compile a normal console application I also get error telling:
error C1069: cannot read compiler command line
And with cmake I get these errors, and I think the above error is related to it.
Determining if the C compiler works failed with the following output:
Change Dir: C:/Users/Amar Thapa/Desktop/glm bin/CMakeFiles/CMakeTmp
Run Build Command:C:\Program Files\MSBuild\12.0\Bin\MSBuild.exe cmTryCompileExec2330384412.vcxproj /p:Configuration=Debug /p:VisualStudioVersion=12.0
Microsoft (R) Build Engine version 12.0.21005.1
[Microsoft .NET Framework, version 4.0.30319.18408]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 12/23/2013 12:50:51 AM.
Project "C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\cmTryCompileExec2330384412.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "cmTryCompileExec2330384412.dir\Debug\".
Creating directory "C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\Debug\".
Creating directory "cmTryCompileExec2330384412.dir\Debug\cmTryCom.89557F4B.tlog\".
InitializeBuildStatus:
Creating "cmTryCompileExec2330384412.dir\Debug\cmTryCom.89557F4B.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec2330384412.dir\Debug\\" /Fd"cmTryCompileExec2330384412.dir\Debug\vc120.pdb" /Gd /TC /analyze- /errorReport:queue testCCompiler.c
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec2330384412.dir\Debug\\" /Fd"cmTryCompileExec2330384412.dir\Debug\vc120.pdb" /Gd /TC /analyze- /errorReport:queue testCCompiler.c
testCCompiler.c
testCCompiler.c(12): fatal error C1069: cannot read compiler command line [C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\cmTryCompileExec2330384412.vcxproj]
Done Building Project "C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\cmTryCompileExec2330384412.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\cmTryCompileExec2330384412.vcxproj" (default target) (1) ->
(ClCompile target) ->
testCCompiler.c(12): fatal error C1069: cannot read compiler command line [C:\Users\Amar Thapa\Desktop\glm bin\CMakeFiles\CMakeTmp\cmTryCompileExec2330384412.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.34
What is a path added in Additional Include Directories relative to? Is it the location of the project (.vcxproj)? Is it the location of the solution (.sln)?
According to my test, the path is relative to the project directory, which is set to current during the project build. I created the project with two source files: test.cpp and dir1\test2.cpp. Both include file test_include.h, which is placed in the parent directory. Additional include directory is: ..\ Build log:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I..\ /ZI /nologo /W3 /WX- /Od /Oy- /D WIN32 /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Yu"StdAfx.h" /Fp"Debug\test.pch" /Fo"Debug\\" /Fd"Debug\vc100.pdb" /Gd /TP /analyze- /errorReport:prompt dir1\test2.cpp test.cpp
test.cpp
test2.cpp
As you can see, current directory is the project directory, and files in the command line are: dir1\test2.cpp and test.cpp, both are successfully compiled with the same /I..\ switch.