Изменение компилятора с MinGW32 на clang в CodeLite (Windows) приводит к ошибкам компиляции

У меня есть проект, который успешно строится с использованием MinGW32 в Windows 8.1 с использованием CodeLite. Я пытаюсь изменить компилятор с MinGW32 на clang. Однако после переключения компилятора я получаю следующую ошибку:

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

...за которым следуют многие другие в том же духе. Итак, я попытался сделать более простую программу, чтобы проверить, была ли программа просто в моем коде, и мне «повезло» с MinGW32.

Следующая программа также показывает ту же ошибку:

#include <iostream>

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

В CodeLite установлены следующие параметры компилятора (они не изменились между компиляторами):

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

Я также попытался установить флажок Enable C++11 Standard (clang) на уровне рабочей области, просто чтобы быть уверенным.

После недолгих поисков в интернете нашел следующую проблему:

Сбой сборки из-за ошибок clang. #762

В результате я попытался добавить -fno-ms-compatibility к своим параметрам компилятора. Похоже, это имело эффект, поскольку ошибка компилятора изменилась на:

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

Я попытался использовать популярную поисковую систему, чтобы найти решение и для этой проблемы, но все, что я смог найти, это ссылку на него внутри файла с именем MicrosoftMangle.cpp. Вот часть, в которой упоминается ошибка, с которой я столкнулся:

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;
  }
  }
}

На данный момент у меня нет идей о том, как решить мою проблему, отсюда и этот вопрос. Заранее благодарю вас за любую помощь, которую вы можете мне оказать!

Дополнительная информация

Я понимаю, что я все еще использую здесь каталоги включения MinGW32, и это сделано намеренно как это руководство по CodeLite предложил мне сделать это.


person OMGtechy    schedule 06.08.2014    source источник
comment
VC++ еще не имеет фундаментальных типов для char16_t и char32_t — в настоящее время они являются просто определениями типов для других фундаментальных типов — поэтому они также еще не являются частью MS ABI. Следовательно, если clang ожидает, что ABI различает, например, char16_t и unsigned short, то правильно ошибиться.   -  person ildjarn    schedule 07.08.2014
comment
@ildjarn Я не намеревался смешивать VC++ и MinGW32, хотя из того, что вы говорите, кажется, что это так. Я также не очень хорошо знаком с CodeLite (только недавно начал его использовать) или clang; есть ли решение для этого? Спасибо за ваши усилия до сих пор.   -  person OMGtechy    schedule 07.08.2014
comment
Я не знаю, как выполнить то, что вам нужно, поэтому я не могу опубликовать правильный ответ, но основная проблема заключается в следующем: в Windows clang может использовать стандартную библиотеку libstdc++ или VC++. . Ваша копия clang, очевидно, настроена на использование libstdc++, который ожидает, например. char16_t должен быть типом, отличным от unsigned short, но в VC++ это один и тот же тип. Я сильно подозреваю, что если вы заставите clang использовать стандартную библиотеку VC++, тогда все встанет на свои места (и вам нужно будет избегать -fno-ms-compatibility).   -  person ildjarn    schedule 07.08.2014
comment
@ildjarn Большое спасибо, это, по крайней мере, дает мне некоторое представление о том, куда идти дальше.   -  person OMGtechy    schedule 07.08.2014
comment
К сожалению, эта страница предполагает, что это пока невозможно (возможно, на 3,5, не знаю).   -  person ildjarn    schedule 07.08.2014
comment
@ildjarn Возможно, поможет пересборка clang (и, возможно, LLVM) с использованием mingw32, а не MSVC. Из информации, которую вы мне дали, кажется, что в настоящее время VC++ не вариант.   -  person OMGtechy    schedule 07.08.2014


Ответы (1)


Чтобы упростить задачу: я почти уверен, что clang не готов для разработки под Windows. Кроме библиотеки автозавершения кода, я не видел ни одного производственного приложения, успешно скомпилированного с помощью clang под MSW.

Обратите внимание, что мне удалось создать простой приветственный мир, но он с треском провалился при его запуске (особенно когда задействованы исключения)

Короче говоря: придерживайтесь MinGW (gcc) для Windows, это самая надежная вещь, которую вы получите.

Вот результат создания простого приветственного мира с помощью codelite на моей машине (используя clang 3.4, загруженный с веб-сайта LLVM, и позволив codelite обнаружить его из настроек-> настройки сборки-> автоопределение компиляторов):

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

Однако он отлично компилируется, когда я запускаю его - он печатает сообщение «hello world» и мгновенно падает.

Обратите внимание, что причина, по которой clang использует пути включения MinGW, проста: он не поставляется со своими собственными файлами заголовков, вместо этого он полагается на их существование (codelite использует пути включения компилятора MinGW «по умолчанию» и использует их для clang)

В заключение: я настоятельно рекомендую вам придерживаться MinGW или VC.

Эран (автор CodeLite IDE)

person Eran    schedule 07.08.2014
comment
Эран (автор CodeLite IDE) Что ж, теперь мы не можем не поставить +1, не так ли? - person ildjarn; 07.08.2014
comment
Спасибо. Я с нетерпением жду того дня, когда clang действительно заработает в Windows! Может даже пойти и взглянуть на источник, чтобы узнать, могу ли я чем-то помочь. - person OMGtechy; 07.08.2014
comment
@Eran Я до сих пор не могу заставить clang работать в CodeLite. есть ли где-нибудь тема для отслеживания прогресса? - person Candy Chiu; 08.05.2015
comment
@CandyChiu Лучшее место будет на форуме CodeLite. Если такой темы нет, создайте новую. Но с CodeLite 8.0 (дата выпуска: воскресенье) вы должны быть в состоянии скомпилировать, по крайней мере, образец hello world с помощью CodeLite + clang в Windows (в Linux и OSX это работает без проблем, на самом деле в OSX CodeLite собран с clang) - person Eran; 08.05.2015
comment
@GaretClaborn Я не думаю, что Clang действительно хорошо работает в Windows и не входит в их список приоритетов. Вы консультируетесь со списком рассылки clang dev, работает ли он в Windows с MinGW. К вашему сведению: я без проблем работаю с Clang на OSX/Clang. Проблема в компиляторе, а не в IDE - person Eran; 20.07.2017
comment
@Eran отлично работает для меня в CodeLite с MinGW уже больше года. Я только задавался вопросом, планировал ли CodeLite когда-либо обновлять автоматические настройки, чтобы они соответствовали текущему процессу, который все используют для clang в стиле posix, в основном просто используя libstdc++ gcc. установка по умолчанию (clang в стиле msvc) теперь активно поддерживается Microsoft и, по сути, имеет тот же самый abi, что и Visual Studio, но с clang. сейчас есть много производственного кода, в том числе в ms. довольно удобно проверять, как кроссплатформенные функции работают с библиотеками, которые не были созданы с учетом win32. - person Garet Claborn; 21.07.2017