In file included from C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\iostream:39:
In file included from C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\ostream:39:
In file included from C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\ios:38:
In file included from C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\iosfwd:41:
In file included from C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\bits/postypes.h:41:
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:144:11: error: no member named 'fgetws' in the global namespace
using ::fgetws;
~~^
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:146:11: error: no member named 'fputws' in the global namespace
using ::fputws;
~~^
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:150:11: error: no member named 'getwc' in the global namespace
using ::getwc;
~~^
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:151:11: error: no member named 'getwchar' in the global namespace
using ::getwchar;
~~^
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:156:11: error: no member named 'putwc' in the global namespace
using ::putwc;
~~^
C:\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cwchar:157:11: error: no member named 'putwchar' in the global namespace
using ::putwchar;
~~^
6 errors generated.
Build error occurred, build is stopped
Time consumed: 646 ms.

The obvious question is - why do I get this?

Additionally, I would like to know more details, and since, Clang website provides extremely brief information - I thought that somebody could clarify the following questions to me:

As far as I understand Clang does not have its own standard library (stdc++ I guess, isn't it?). That's why I have to use MinGW's headers and libraries - am I right?

What is the difference between building Clang with Visual Studio and MinGW?

Do I have to hard-code include paths in clang/lib/Frontend/InitHeaderSearch.cpp or I can skip it and rather specify those paths later through "-I" option as I do in the screenshot above?

The combination I've gotten to work in the past is to modify InitHeaderSearch.cpp to include the path to my MinGW include folders and then to build with the MinGW toolchain. I've also been able to build using the Visual C++ toolchain, but I wasn't able to figure out how to get the built compiler to utilize the headers and libraries from the MinGW install (the Visual C++ C++ Standard Library headers can't be used because they rely extensively on Visual C++-specific features).
–
James McNellisJan 16 '12 at 16:13

3

Yeah that's exactly what I was thinking of. But the biggest confusion to me is how building with either Visual C++ or MinGW is related to include and library paths used during the utilization of Clang compiler. In other words, I have to able to freely choose these paths after having compiled Clang. Why on earth would these paths depend on the compiler that I used to build Clang?
–
HarooganJan 16 '12 at 16:25

1

@JamesMcNellis: Clang should be able to parse VC++ headers currently. The only problematic parsing area is MFC IIRC.
–
rubenvbJan 16 '12 at 18:27

1

@Haroogan I completely agree with what you are saying. I have been trying to get the clang plugin working on Sublime Text 2 on Windows and the strange stdc++/header problems are... well, strange.
–
Steven LuSep 14 '12 at 4:20

2 Answers
2

If you build Clang with MSVS, it will automatically search the default VS include paths, and pull in those headers. This is the reason the libstdc++ headers are producing errors: they are importing C functions not present in the VS headers. Using Clang for C++ with VS is for now a no-go: you will get link failures due to missing ABI (name mangling and others) functionality in Clang. If you still want to use the MSVS Clang, don't point it to MinGW headers. It will parse the VS headers (including C++), it just will fail to link.

EDIT: I have built a dw2 version of GCC (32-bit only) accompanied by Clang. Exceptions work in this build, and so you can build real C++ stuff with Clang now on Windows. Get version 3.2 here.

@Haroogan: I injected MinGW-w64's include paths into InitHeaderSearch.cpp and plan to maintain that until that code is superceded by something better. The paths are hardcoded into Clang. the important thing is that this means that you don't have to worry about any of this, and you can just do clang somefile.c -o test.exe, without the need to add standard include paths to the commandline. Same goes for GCC: it knows where all its headers are located too.
–
rubenvbJan 16 '12 at 18:32

1

Alright, but honestly it's a mess that the official guide for building Clang on Windows suggests to build it with Visual Studio while knowing that it will then use Visual C++ Standard Library which immediately leads to epic fail...
–
HarooganJan 16 '12 at 18:36

5

@rubenvb: Care to share the steps needed to reproduce your build? Would be an immense help.
–
marton78Jul 18 '12 at 9:31

The obvious answer is you forgot sending -fno-ms-compatibility to clang++ :P

You are right.

VC++ is GUI tool-chain, MinGW is character console.

No as clang is mature enough for public consumption but still to stabilize so let its dev team work on the code otherwise you risk work that might become lost island. I'm using -I as your example suggests.