When I had Clang 3.7 installed it would find the STL headers from my GCC installation as long as only both those two directories in the path.
Now that I have installed Clang 3.8 the compiler keeps finding the Visual Studio headers despite the fact that it isn't even in the path
My path is as follows:
PATH=whatever;G:\Compilers\LLVM\bin;g:\compilers\Mingw64-64bit\bin
Edit 1
I've know idea what the correct include paths, but I tried a compilation in Codelite which found these:
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\x86_64-w64-mingw32"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include-fixed" "-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\backward"
I'm also using the dialect flag --std=c++11
However a very simple program using the C++ library is giving me errors such as
G:\Compilers\Mingw64-64bit\x86_64-w64-mingw32\include\c++\bits/stringfwd.h:63:33: error: use of undeclared identifier 'char16_t'
template<> struct char_traits<char16_t>;
^
Edit 2
Now passing x86_64-w64-mingw32 as recommended by Martin, the autodiscovery process seems to work, however the produced executable just freezes.
I found the same when I tried to use the VS2015 Clang toolset
The code example I am using is this
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I am now compiling with:
clang++ -v --target=x86_64-w64-mingw32 hello.cpp -o test.exe -std=c++14
I have looked at the executable produced with Dependency Walker and it is showing as a 64 bit compile and linking to "g:\Compilers\Mingw64-32Bit\bin\libstdc++-6.dll"
I think the next step would be to try compiling a 32 bit version, but I cannot seem to find the correct target name for that
I have just tried clang++ hello.cpp -o main.exe -std=c++14 --target=i686-pc-mingw32 -v
That seems to be producing a 32 bit executable, but again it just freezes
Note I updated the path to point to the 32 bit clang.
Edit 3
What I find confusing is that until I passed x86_64-w64-mingw32 as the target I got very similar errors both from passing the GCC paths, and from the default target of MSVC where both seemed to be related to char16_t and similar types
Seeing this I thought I would try if passing a target might fix the VC compiler errors
Whilst that sort of seems to work it just creates more problems, because it keeps asking for libs to link to and I don't know the correct ones
So I tried:
clang++ hello.cpp -o main-vc.exe -std=c++14 --target=x86_64-pc-windows-msvc19.0.0 -v
-Xlinker "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcpmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libvcruntime.lib"
"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\ucrt\x64\libucrt.lib"
I have no idea what were the correct directories to pass.
I have a feeling that I need to pass another lib file as I am getting this error
libcmt.lib(thread_safe_statics.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle
Did you change the target? VC is the new default. Use this (example) for x64, mingw:
clang++ --target=x86_64-w64-mingw32 test.cpp
Don't forget the linker as wel.
Related
I have the main.cpp on Windows at C:\repo\pdfium\out\debug\obj\test directory. Pdfium.lib is at obj directory.
#include <stdio.h>
#include <fpdfview.h>
int main() {
FPDF_InitLibrary();
FPDF_DestroyLibrary();
printf("PDFium hello.\n");
return 0;}
pdfium.lib is build with GCC(is_lang=false)
With command i am producing main.o
g++.exe -std=c++11 -g -I........\public -c
C:\repo\pdfium\out\debug\obj\test\main.cpp -o obj\Debug\main.o
With command bellow i am trying to link pdfium.lib
g++.exe -o bin\Debug\test.exe obj\Debug\main.o ..\pdfium.lib
But i am taking ...
Warning: corrupt .drectve at end of def file
..\pdfium.lib(obj/core/fpdfapi/parser/parser/fpdf_parser_utility.obj):(.xdata[$unwind$?_Makestr#_System_error#std##CA?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##2#Verror_code#2#V32##Z]+0x8): undefined reference to `__GSHandlerCheck'
I have try so many time but nothing on linking on windows 10.
Any advice will be redemptive.
Thank you
Jim
If you're building PDFium with a non-component build (is_component_build = false in args.gn) and not setting pdf_is_complete_lib = true, the generated .lib files won't have their dependencies included, so you're quite likely to have the linker complain about missing symbols. Try either generating DLLs (is_component_build = true) or setting pdf_is_complete_lib = true.
If you use a component build, you'll need to package the PDFium DLL and its dependencies (at least the zlib DLL, possibly others) with your application.
I have both MinGW gcc and Clang clang installed and added to path via chocolatey, and both can be found on the command line. However, when I try to use clang with gcc, clang doesn't seem to know where to find header files in the standard library (such as iostream), returning the following error:
clang++ -v main.cpp -o main.exe -std=c++14 -target x86_64-mingw64
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
(SKIP)
ignoring nonexistent directory "(nonexistent directories)"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\lib\clang\9.0.0\include
End of search list.
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
shell returned 1
I've added both gcc and clang to path, as well as the directory containing header files included in gcc (C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0), so I don't understand why clang isn't looking in the right place for the header files. How can I fix this problem? And this isn't really necessary, but can the default target for clang be changed? The current Windows 10 default for clang is msvc, but I'd rather not use it.
Solution:
edit your path environment, move or add [path to your g++ folder] to some position ahead of "C:\ProgramData\Chocolatey\bin".
Reason:
LLVM installed using prebuilt binaries from chocolatey or its offcial website lacks header files, therefore it has to use header files of other compiles such as MSVC or mingw64. When you specify your target as mingw64, clang will guess path to header files of mingw by the position of g++.exe (maybe gcc.exe).
Chocolatey uses a software shimgen to "map" (I don't know if there is more proper word) executable file to "C:\ProgramData\Chocolatey\bin", which is placed before [path to your g++ folder]. Therefore clang will detect "g++.exe" under that path first and infer a wrong path from it.
Please forgive my poor English.
I'm trying to identify Windows version using IsWindows10OrGreater() and other related functions.
C++, Windows 7 Home Basic, Visual Studio Code v1.36.1, VSCode Extensions - C/C++ for Visual Studio Code, MinGW g++ v8.2.0
Compilation command:
g++ -std=c++11 main.cpp -o file.exe -s -lws2_32 -Wno-write-strings -fno-exceptions -fmerge-all-constants -fpermissive -static-libstdc++ -static-libgcc
I included the version helper header using #include <Versionhelpers.h>, but IntelliSense doesn't recognize it and the build also fails with the error:
fatal error: Versionhelpers.h: No such file or directory
#include <Versionhelpers.h>
I tried including the header in a fresh file and building it, but that didn't work either.
#include <Versionhelpers.h>
int main() {
IsWindowsServer();
return 1;
}
Is there any extension that I need to install in VSCode to get this to work? Or perhaps download the header file (and put it where?)
I'm trying to compile a CUDA C code in Windows command line. I've already installed cuda toolkit and nvcc works fine. But the code includes png.h and I'd like to know what is the proper way to provide it.
Specifically, I want to learn what are the default directories in which nvcc looks for headers and .dlls. And how should I install such standard C libraries: do I necessarily have to use MinGW and somehow add C:\MinGW\include and C:\MinGW\bin to the PATH?
Currently my solution looks in the following way:
$ nvcc mandelbrot-dynamic.cu -O3 -arch=sm_35 -rdc=true -lcudadevrt -Xcompiler -fopenmp -Ic:/mingw/include/ -o dynamic
And the result is:
cl : Command line warning D9002 : ignoring unknown option '-fopenmp' mandelbrot-dynamic.cu
c:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/amd64/../../../VC/INCLUDE\yvals.h(472) : warning C4005: '_EXTERN_C' : macro redefinition
c:/mingw/include/_mingw.h(258) : see previous definition of '_EXTERN_C'
c:/mingw/include/float.h(38) : fatal error C1021: invalid preprocessor command 'include_next'
It doesn't complain about png.h but there is conflict between MSVC and MingW. Plus, nvcc doesn't accept a preprocessor command from a mingw header.
I followed instructions at http://clang.llvm.org/get_started.html
I compiled latest trunk of llvm and clang with MSVC 2010. Now I can compile simple programs with Clang but when I tried to compile this program I got a lot of errors.
Here is program:
#include <algorithm>
int main(){ return 0; }
And here are some of errors:
In file included from hello.cpp:1:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\algorithm:6:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\memory:987:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h:24:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\immintrin.h:32:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\xmmintrin.h:988:
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1384:22: error: expected expression
return (__m128)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1390:23: error: expected expression
return (__m128i)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1396:23: error: expected expression
return (__m128d)__in;
^
Complete output from Clang: http://pastebin.com/qi87K8qr
Clang tries to use MSVC headers but it doesn't work. Maybe I should use libc++ or libstdc++ instead, but how to do that?
Note I'm not interested in precompiled clang binaries
Yes, clang simply does not support all of Microsoft's extended C++ syntax, and therefore cannot parse Microsoft's C++ headers which use that syntax. Not only that but Clang also doesn't have complete support for Microsoft's C++ ABI, name mangling, etc. I believe Clang on Windows works alright with C, however.
To use a different C++ standard library instead you can make clang ignore the normal header and library directories with, IIRC, -nostdinc++ and -nostdlib++. Then you can tell clang the include and library directories you want to use (using -isystem or -I or whatever). However I'm not sure whether libc++ or libstdc++ work under those circumstances, since they probably depend on things that the Windows C runtime library does not have.
Chandler Carruth mentioned at Going Native 2013 that there are now alpha builds of clang for Windows with Visual Studio integration. Lots of stuff is broken, for example, streams (so good old hello world won't work). However, there is a lot of effort being put into making clang work on Windows, so expect it to get pretty good pretty fast.
Errors were in the header supplied with clang itself. Looks like it can't handle MMX/SSE types properly. Try to add -msse -msse2 switches to the command line.
I'm using libstdc++ and built clang using VS2012Express for desktop. The cmake string was "Visual Studio 11 Win64" and the essential dirs. are specified using -I argument.
My guess you program could work if I used mingw headers for Windows.