Windows 10: Clang, "stdio.h" not found [duplicate] - c

This question already has answers here:
clang/clang++ doesn't find C/C++ headers in windows?
(3 answers)
Closed 6 years ago.
I have installed LLVM and Clang-3.9.0 on Win10. I have MinGW installed as well.
I have put my C code in 'D:' drive.
I can use gcc and g++ to compile my code. But when I use clang I get:
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-pc-windows-msvc
ignoring duplicate directory "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A"
ignoring duplicate directory "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\bin\..\lib\clang\3.9.0\include
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A
End of search list.
hello.c:1:10: fatal error: 'stdio.h' file not found
#include "stdio.h"
^
1 error generated.
As I can use gcc and g++, my environment variable settings are right. But then I am not able to force clang to look into C:\MinGW.
I tried copy pasting the whole MinGW folder manually in C:\Program Files\LLVM\bin\ and \lib\clang\3.9.0\include separately, but it did not work. I wanted to try this, but in 3.9.0 I cannot find, clang/lib/Frontend/InitHeaderSearch.cpp.
Anyway, is there a work around?
Note: I have tried <stdio.h> and "stdio.h" both, and I still get the same error.

Okay, so until now things with Clang/LLVM in Windows. Starting 3.7 or so things have changed: Clang/LLVM binaries are built with Visual Studio and for Visual Studio. No need for MinGW, as far as I understand.
So now install LLVM via the binary files available. Make sure that you have VS2015 (or 2013 and more) previously installed. When LLVM is being installed add it in the path when prompted.
Now after all that has been done, start the developer commander prompt for VS2015 (got to start -> Visual Studio 2015 -> Developer Commander Prompt for VS2015. I guess, you will choose whatever suits for your requirements). Now from here try using the clang commands listed on LLVM website.
However commands like lli, llvm-dis and llc still cannot be ran.
Also, LLVM website still says that GNU tools for windows are needed. But I do not know what for!

Related

installing GSL library for C programming in windows

I want to install the GSL library (https://www.gnu.org/software/gsl/) in windows. I have downloaded the files but i do not know what to do apart from that in order to be able to use the functions of the library (apart from the #include <...> in my program.c file).
I am using visual studio code and i have installed mingw.
Thanks in advance
EDIT
I am adding more information about this issue. I am not the original poster, but I have the same problem.
I am trying to use the GSL and I work with Visual Studio Code on Windows 10.
I have already installed the basic packages to work with C/C++ in
Visual Studio Code. More precisely, if I am not wrong, VS Code is
using the compiler gcc.exe from mingw64 (last version). This was
installed using an 'extension' available at VS Code (https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools).
I downloaded the last version of the GSL (2.7) and unzipped it.
I get stuck when I try to follow the installation instructions. When I
execute either .\configure or ./configure in the DOS command line,
I get an error of "unknown command" (even if I am placed in the same directory where the file is stored).
When I execute .\configure in PowerShell, I get a message asking me
which programme should be used to open this file.
And here is where I get lost. :/
I have discovered an alternate path, which is installing GSL from vcpkg (https://vcpkg.io/). This is suggested by VS Code, actually. This vcpkg seems to be a programme by Microsoft to make it easier to install third-party C/C++ packages in Windows.
The specifications to install vcpkg are (https://vcpkg.io/en/getting-started.html):
Windows 7 or newer
Git
Visual Studio 2015 Update 3 or newer
I can try this path, but first I would like to be sure there is no easier way (installing Visual Studio to not really use it seems a lot to me!).

How to solve libatomic issue in windows?

I am developing executables from source code of llvm. So I downloaded the llvm source code from github.
I am trying everything from command line on Windows OS
I am following the link for libtooling in clang
http://clang.llvm.org/docs/LibASTMatchersTutorial.html
I tried with 2 options
Option First: I ran the below command
cmake -G Ninja "C:\Users\amith.ks\Desktop\Clang-llvm\llvm-project\llvm" -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DLLVM_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release
Everything Worked..
Second option:
I wan to set cmake_c_compiler and cmake_cxx_compiler from command line.
I dont want to use cmake-gui so I run the below command
cmake -G Ninja "C:\Users\amith.ks\Desktop\Clang-llvm\llvm-project\llvm" -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DLLVM_BUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
From out of no where error was thrown
CMake Error at cmake/modules/CheckAtomic.cmake:53 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:343 (include)
CMakeLists.txt:617 (include)
When I saw the cmake error log It was saying this
LINK : fatal error LNK1104: cannot open file 'atomic.lib'
clang: error: linker command failed with exit code 1104 (use -v to see invocation)
ninja: build stopped: subcommand failed.
I searched my whole pc atomic.lib no where to be found.
How to solve this issue on windows?
Please help me with answers.
I know why it fails. It's a bug in the LLVM's cmake files. In order to check if atomic.lib is required CheckAtomic.cmake tries compiling and linking a piece of code with atomic.lib. When it fails (because atomic.lib is not required and thus is not present) it falsely concludes that atomic.lib is needed. LLVM's cmake files is a hot mess with rarely fixed bugs. There are bugs staying there for years. I guess this is because nobody understands anymore how LLVM build system works.
Long story short, I couldn't find why CheckAtomic.cmake inserts atomic.lib while checking that it is not required. As a workaround I just unconditionally set HAVE_CXX_ATOMICS64_WITHOUT_LIB and HAVE_CXX_ATOMICS_WITHOUT_LIB to True in CheckAtomic.cmake:
set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True)
set(HAVE_CXX_ATOMICS_WITHOUT_LIB True)
Use clang-cl (or MSVC cl), they dont require lib atomic.
I'm trying to use Clang 11 (with MSVC ABI) to compile Clang 11. However, MSVC's headers won't compile in C++11 mode, which CheckAtomic.cmake uses:
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++11")
results in:
C:\Users\nyanpasu\code\llvm-project>clang -Werror=unguarded-availability-new -std=c++11 uwu.cpp
In file included from uwu.cpp:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\atomic:19:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\xatomic.h:13:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\type_traits:11:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\xstddef:283:22: error: 'auto' return
without trailing return type; deduced return types are a C++14 extension
_NODISCARD constexpr auto _Unfancy(_Ptrty _Ptr) noexcept { // converts from a fancy pointer to a plain pointer
^
1 error generated.
I don't know if this is a MSVC bug where it ships an header incompatible with C++11, or a Clang bug where it's using MSVC headers instead of its own.
In any case, changing c++11 to c++14 fixes this error.
As lulle mentioned, you need to use the right tools to compile. If you have installed Visual Studio, use the Developer Command prompt for Visual Studio instead of a regular cmd and you'll have the environment variables you need. It is located in your Visual Studio installation directory, under the Tools subdirectory.
For example:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat
I encountered the same error in macOS. Adding the CPP Libraries to the path solved it for me. You can try executing the following commands.
export SDKROOT="$(xcrun --sdk macosx --show-sdk-path)"
export CPLUS_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1

Unable to set compiler in CMake

Can someone help me set up compiler for CMake and thus help me understand how all this works? I intend to use point cloud library, but I'll use more simple example here (which is also not working) so I could explain my problem better.
I have next components:
Visual Studio 10 (C:\Program Files (x86)\Microsoft Visual Studio 10.0)
CMake 3.7.2 (C:\Program Files\CMake)
"hellocmake" project - complete file structure as presented here (C:\Users\my_name\Documents\Visual Studio 2010\Projects\hellocmake)
I tried to run CMake Gui, pointed to a source and build folders, configured for "Visual Studio 10 2010 Win 64" and run out as expected with:
"The C compiler identification is unknown
The CXX compiler identification is unknown"
I understand I need to setup compiler, but I'm not sure at this point what should I do. I tried so far:
From visual studio open command prompt, navigate to CMake and run "cmake -D CMAKE_CXX_COMPILER="g++" CMAKE_CC_COMPILER="gcc"
Output: "The C compiler identification is unknown. The CXX compiler identification is unknown. No CMAKE_C_COMPILER could be found"
g++ was not a full path and was not found in PATH
I added C:\Program Files\CMake\bin and C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe to Environment Variables -> PATH and tried all again. I have the same output as above.
Putted these lines in CMakeLists.txt inside C:\Program Files\CMake:
SET(CMAKE_C_COMPILER C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe)
SET(CMAKE_CXX_COMPILER C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe)
and ended up with the same "No CMAKE_C_COMPILER could be found" output.
Also tried to put a quotes for CMAKE_C_COMPILER path, to use CMAKE_CXX_COMPILER:PATH in command prompt, to run CMake Gui as admin and nothing works.
I really don't know what to try more now. Also, I'm not sure how all this work after so many unsuccessful trials.
Any help will be highly appreciated. Thanks!
EDIT:

GTK Linker Issue Visual Studio C Project

it is the third day that I am trying to set up the visual studio 2013 with the GTK libraries. I need to use VS: I've used GCC (both command line and with code blocks) in the past (both on windows and slackware linux too..), but now I have a lot of projects in VS and I want to start making some GUI for them. After seeing that the so called "all-in-one-bundle" is not more available/maintained in the GTK website, I followed a bunch of tutorials (including GTK+ 3.0 setup in Visual Studio 2013, How to configure gtk on Visual studio 2010, How do you install GTK+ 3.0 on Windows?) and I started to install MSYS2 according to this one: https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/.
Maybe the problem is here: I followed this step properly pacman -S mingw-w64-x86_64-toolchain, but I skipped the creation of PKGBUILD file and successive installation due to the fact that I did not understand the procedure. Furthermore the mingw toolchaing seemed to be already installed.
Sorry for the big introduction, I wanted to be specific.
The problem is at the linking-stage of Visual Studio C Project building. I had also some problem at compilation involving the different inline interpretation of VS (added #define inline __inline // Necessary to make the GTK library Visual Studio compatible definition before calling the GTK header). The linking stage issue consist in the fact that, using pkg-config --libs gtk+-3.0 --msvc-syntax command, I receive a list of files (/libpath:C:/msys64/mingw64/lib gtk-3.lib gdk-3.lib gdi32.lib imm32.lib shell32.lib ole32.lib -Wl,-luuid winmm.lib dwmapi.lib z.lib pangowin32-1.0.lib pangocairo-1.0.lib pango-1.0.lib atk-1.0.lib cairo-gobject.lib cairo.lib gdk_pixbuf-2.0.lib gio-2.0.lib gobject-2.0.lib glib-2.0.lib intl.lib) that does not exists in the msys2 directory. As a consequence I receive this error from the linker: error LNK1104: cannot open file 'gtk-3.lib'.
Someone has the same problem (see Error 3 error LNK1104: cannot open file 'gtk-3.lib'), but the solution is to use the all-in-one-bundle.
What shall I do? Have I followed the correct procedure or am I missing something? I've also tried to link to VS the *.a files located in the lib directory of mingw63 (e.g. libgtk-3.dll.a), but the linker error remains.
Best Regards and thank you for the attention
Davide

Missing sal.h while compling a win32 project via mingw

Error message:
fatal error: sal.h: No such file or directory cstudy line 11, external
location: C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Include\specstrings.h C/C++ Problem.
But when I add VC/include to this project,I received a ton of error messages. It seems VC/include/sal.h is not a standard header file for GCC.
The source code is very simple:
#include "windows.h"
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
return 0;
}
Environment:
Windows 7.0A SDK
VC 2010
MINGW
CDT/ECLIPSE.
Thanks.
No, the sal.h header is not part of GCC / MinGW, however you can add your VC/include/ as an include directory to eclipse.
alternative: move all (!) requried headers to your mingw or project include directory. The one from MinGw is: <mingw path>/include).
Anyway. sal.h, if you install the Windows SDK then it isn't going to
be in the SDK directory, but you should find that if you select to
install the compiler and tools it will get installed along with that.
This is because sal.h is needed in the CRT headers as well as the
Windows headers. So you NEED to install the VS compilers and tools
along with the SDK. You will then find that the compiler will be
installed by default under %ProgramFiles%\Microsoft Visual Studio
2010\VC and sal.h will be in include under that path. On 64 bit
systems it will be under %ProgramFiles(x86)% by default.
source: http://social.msdn.microsoft.com/Forums/eu/windowssdk/thread/0e166050-99f1-436b-bd94-b39e2910f43d
See:
can't find sal.h (!)
Windows SDK header files question
I just ran into this problem. I can't seem to get the sal.h header file through the MS Windows version of mingw, but "yum whatprovides \*/sal.h" on my Fedora Core 18 machine brought up the mingw-headers package. I downloaded the source package (i.e. yumdownloader --source mingw-headers), opened up the .tar.gz file in file-roller, grabbed the sal.h file, and put it in /c/MinGW/include on my MS Windows machine.
The same package had dsound.h, which was the next missing header file.
I've never tried to use mingw under Fedora Core to cross-compile MS Windows apps, but maybe it's time... :-)

Resources