2

I have a project the successfully builds using MinGW32 on Windows 8.1 using CodeLite. I am trying to change the compiler from MinGW32 to clang. However, after switching the compiler over I get the following error:

c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++\bits/stringfwd.h:74:33: error: use of undeclared identifier 'char16_t'

...followed by many others of a similar nature. So, I tried making a simpler program to check if the program was simply in my code and I'd been 'lucky' with MinGW32.

The following program also exhibits the same error:

#include <iostream>

int main(int argc, char **argv)
{
    std::cout << "Hello World" << std::endl;
    return 0;
}

Within CodeLite, the following compiler options are set (these have not changed between compilers):

-g;-O0;-Wall;-std=c++11

I've also tried checking the Enable C++11 Standard (clang) box at the workspace level, just to be sure.

After some searching on the internet, I found the following issue:

Build fails on clang errors. #762

As a result of this, I tried adding -fno-ms-compatibility to my compiler options. This did seem to have an effect, as the compiler error changed to:

c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++\bits/char_traits.h:391:7: error: cannot mangle this built-in char16_t type yet

I tried using a popular search engine to find a solution to this too, but all I could find was a reference to it inside a file called MicrosoftMangle.cpp. Here is the part which mentioned the error I encountered:

void MicrosoftCXXNameMangler::mangleType(const BuiltinType *T,
                                         SourceRange Range) {
  //  <type>         ::= <builtin-type>
  //  <builtin-type> ::= X  # void
  //                 ::= C  # signed char
  //                 ::= D  # char
  //                 ::= E  # unsigned char
  //                 ::= F  # short
  //                 ::= G  # unsigned short (or wchar_t if it's not a builtin)
  //                 ::= H  # int
  //                 ::= I  # unsigned int
  //                 ::= J  # long
  //                 ::= K  # unsigned long
  //                     L  # <none>
  //                 ::= M  # float
  //                 ::= N  # double
  //                 ::= O  # long double (__float80 is mangled differently)
  //                 ::= _J # long long, __int64
  //                 ::= _K # unsigned long long, __int64
  //                 ::= _L # __int128
  //                 ::= _M # unsigned __int128
  //                 ::= _N # bool
  //                     _O # <array in parameter>
  //                 ::= _T # __float80 (Intel)
  //                 ::= _W # wchar_t
  //                 ::= _Z # __float80 (Digital Mars)
  switch (T->getKind()) {
  case BuiltinType::Void: Out << 'X'; break;
  case BuiltinType::SChar: Out << 'C'; break;
  case BuiltinType::Char_U: case BuiltinType::Char_S: Out << 'D'; break;
  case BuiltinType::UChar: Out << 'E'; break;
  case BuiltinType::Short: Out << 'F'; break;
  case BuiltinType::UShort: Out << 'G'; break;
  case BuiltinType::Int: Out << 'H'; break;
  case BuiltinType::UInt: Out << 'I'; break;
  case BuiltinType::Long: Out << 'J'; break;
  case BuiltinType::ULong: Out << 'K'; break;
  case BuiltinType::Float: Out << 'M'; break;
  case BuiltinType::Double: Out << 'N'; break;
  // TODO: Determine size and mangle accordingly
  case BuiltinType::LongDouble: Out << 'O'; break;
  case BuiltinType::LongLong: Out << "_J"; break;
  case BuiltinType::ULongLong: Out << "_K"; break;
  case BuiltinType::Int128: Out << "_L"; break;
  case BuiltinType::UInt128: Out << "_M"; break;
  case BuiltinType::Bool: Out << "_N"; break;
  case BuiltinType::WChar_S:
  case BuiltinType::WChar_U: Out << "_W"; break;

#define BUILTIN_TYPE(Id, SingletonId)
#define PLACEHOLDER_TYPE(Id, SingletonId) \
  case BuiltinType::Id:
#include "clang/AST/BuiltinTypes.def"
  case BuiltinType::Dependent:
    llvm_unreachable("placeholder types shouldn't get to name mangling");

  case BuiltinType::ObjCId: Out << "PAUobjc_object@@"; break;
  case BuiltinType::ObjCClass: Out << "PAUobjc_class@@"; break;
  case BuiltinType::ObjCSel: Out << "PAUobjc_selector@@"; break;

  case BuiltinType::OCLImage1d: Out << "PAUocl_image1d@@"; break;
  case BuiltinType::OCLImage1dArray: Out << "PAUocl_image1darray@@"; break;
  case BuiltinType::OCLImage1dBuffer: Out << "PAUocl_image1dbuffer@@"; break;
  case BuiltinType::OCLImage2d: Out << "PAUocl_image2d@@"; break;
  case BuiltinType::OCLImage2dArray: Out << "PAUocl_image2darray@@"; break;
  case BuiltinType::OCLImage3d: Out << "PAUocl_image3d@@"; break;
  case BuiltinType::OCLSampler: Out << "PAUocl_sampler@@"; break;
  case BuiltinType::OCLEvent: Out << "PAUocl_event@@"; break;

  case BuiltinType::NullPtr: Out << "$$T"; break;

  case BuiltinType::Char16:
  case BuiltinType::Char32:
  case BuiltinType::Half: {
    DiagnosticsEngine &Diags = Context.getDiags();
    unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
      "cannot mangle this built-in %0 type yet");
    Diags.Report(Range.getBegin(), DiagID)
      << T->getName(Context.getASTContext().getPrintingPolicy())
      << Range;
    break;
  }
  }
}

At this point, I am out of ideas on how to solve my problem, hence this question. Thank you in advance for any help you're able to give me!

Additional Information

I realise that I am still using the MinGW32 include directories here, and this in on purpose as this tutorial on CodeLite suggested I do so.

OMGtechy
  • 7,935
  • 8
  • 48
  • 83
  • VC++ does not yet have fundamental types for `char16_t` and `char32_t` – presently they're merely typedefs for other fundamental types – so they're also not yet part of MS's ABI. Consequently, if clang expects that the ABI distinguishes between e.g. `char16_t` and `unsigned short`, then it's right to error out. – ildjarn Aug 06 '14 at 22:04
  • @ildjarn I did not *intend* to mix VC++ and MinGW32, although from what you're saying it seems that this is the case. I'm also not very familiar with CodeLite (only started using it recently), or clang; is there a solution for this? Thank you for your efforts so far. – OMGtechy Aug 06 '14 at 22:08
  • I don't know _how_ to accomplish what you need to do, so I can't post a proper answer, but the underlying problem is this: on Windows, clang can use either libstdc++ or VC++'s standard library. Your copy of clang is obviously configured to use libstdc++, which expects e.g. `char16_t` to be a distinct type from `unsigned short`, but in VC++ they're the same type. I strongly suspect that if you get clang to use VC++'s standard library then everything will fall into place (and you'll need to avoid `-fno-ms-compatibility`). – ildjarn Aug 06 '14 at 22:15
  • @ildjarn Thank you very much, this at least gives me some direction as to where to go from here. – OMGtechy Aug 06 '14 at 22:16
  • Sadly, [this page](http://llvm.org/docs/GettingStartedVS.html) suggests that this isn't yet possible (maybe on tip-of-trunk 3.5, I dunno). – ildjarn Aug 06 '14 at 22:23
  • @ildjarn Maybe rebuilding clang (and possibly LLVM) using mingw32 rather than MSVC will help. From the information you've given me, it seems that at present VC++ is not an option. – OMGtechy Aug 06 '14 at 22:34

1 Answers1

5

To make things simpler: I am pretty sure that clang is not ready for Windows development. Other than code completion library, I have not seen a single production application successfully compiled with clang under MSW.

Note that I did manage to build a simple hello world, but it failed miserably when running it (especially when exception are involved)

Long story short: stick to MinGW (gcc) for Windows, its the most reliable thing you will get

Here the output of building a simple hello world with codelite on my machine (using clang 3.4 downloaded from LLVM website, and letting codelite detect it from settings->build settings->auto detect compilers):

C:\Windows\system32\cmd.exe /c "C:/MinGW-4.8.1/bin/mingw32-make.exe -j8 SHELL=cmd.exe  -e -f  Makefile"
"----------Building project:[ ClangHW - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/src/TestArea/ClangHW'
D:/software/LLVM/bin/clang++.exe   -c  "D:/src/TestArea/ClangHW/main.cpp" -g -O0 -Wall  -o ./Debug/main.cpp.o -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++ -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++/mingw32 -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include/c++/backward -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include -Ic:/mingw-4.8.1/include -Ic:/mingw-4.8.1/lib/gcc/mingw32/4.8.1/include-fixed  -I. -I.
D:/software/LLVM/bin/clang++.exe  -o ./Debug/ClangHW @"ClangHW.txt" -L.
mingw32-make.exe[1]: Leaving directory 'D:/src/TestArea/ClangHW'
0 errors, 0 warnings

It compiles fine, however, when I run it - it prints the "hello world" message and crashes instantly

Note that the reason that clang is using MinGW include paths, is simple: it does not come with its own header files, instead it relies on their existence (codelite uses your "default" MinGW compiler include paths and uses them for clang)

To conclude: I strongly recommend you to stick to MinGW or VC

Eran (Author of CodeLite IDE)

Eran
  • 2,310
  • 1
  • 13
  • 13
  • 1
    "*Eran (Author of CodeLite IDE)*" Well, we can't _not_ +1 it now, can we? – ildjarn Aug 07 '14 at 06:23
  • Thank you. I look forward to the day when clang truely does work on Windows! May even go and take a look at the source to see if I can help. – OMGtechy Aug 07 '14 at 12:15
  • @Eran I still can't get clang to work in CodeLite. is there a thread somewhere for me to follow the progress? – Candy Chiu May 08 '15 at 15:31
  • @CandyChiu The best location will be on CodeLite's forum. If there is no such topic, start a new one. But with CodeLite 8.0 (release date: Sunday) You should be able to compile at least "hello world" sample with CodeLite + clang on Windows (on Linux and OSX its works without a problem, in fact on OSX, CodeLite is built with clang) – Eran May 08 '15 at 19:23
  • @GaretClaborn I don't think that Clang really works well on Windows nor it is on their priority list. You consult with the clang dev mailing list if it works on Windows with MinGW. FYI: I am working with Clang on OSX/Clang without an issue. The problem is with the compiler, not the IDE – Eran Jul 20 '17 at 19:00
  • @Eran working fine for me in CodeLite with MinGW, has been for over a year. I only wondered if CodeLite ever planned to update automatic settings to match the current process everyone uses for posix-style clang, basically just use gcc's libstdc++. the default installation (msvc style clang) is now being maintained actively by microsoft and essentially has the same exact abi as visual studio but with clang. there's lots of production code out there now, including at ms. its pretty convenient to test how cross-platform features are from libraries that weren't built with win32 in mind. – That Realty Programmer Guy Jul 21 '17 at 05:29