LLVM+Clang 3.2: собираем самим собой под Windows

LLVM - это набор "кирпичиков" для построения компиляторов, а clang - новый компилятор C++ на его основе. По сравнению с gcc - обеспечивается большая скорость компиляции при сравнимом качестве кода, более человеко-понятные исходники т.к. они не несут десятилетия жесточайшей C-only разработки как в gcc.

Помимо этого, Clang и llvm распространяются под лицензией BSD, в отличии от GPLv3 у GCC. BSD позволяет не открывать исходники при распространении исполняемых файлов.

С LLVM+CLang будет интересно поиграть любому кто когда-либо хотел написать свой компилятор, или считает, что компилятор собранный своими руками дает более теплый бинарный код.

БОльшая часть часть разработчиков llvm/clang используют его под Linux/MacOS - и там его сборка/установка не вызывает каких либо проблем, путь основательно протоптан. А вот в случае windows ситуация несколько осложняется - об обходе нескольких граблей при сборке, о том, что связывает clang и gcc, и какие баги придется фиксить в релизе - под катом.

Сборка

Существуют 2 основных способа собирать llvm+clang под windows:

CMake позволяет сгенерировать solution для Visual Studio. clang+llvm до сих пор зависит от компонент gcc (стандартной библиотеки например, но работа над устранением зависимости идет), потому даже собирая clang в Visual Studio эта зависимость останется, и у вас получится дичайшая солянка из кусков clang, VS и gcc, где все компоненты со временем будут случайно менять версии. Помимо этого, на данный момент Visual Studio 2012 падает при сборке clang 3.2 с оптимизацией - Microsoft работает над фиксом (в 2010 все ок). В свете этого, я решил Visual Studio не использовать, тем более на конечный результат (clang собранный clang) это не должно особо повлиять.

Mingw32+MSYS. Mingw32 - содержит gcc и тонкую обертку, реализующую linux-подобное окружение для программ, трансляцию путей windows<>linux style. Специфичные функции (вроде fork) полностью не реализованы, потому совместимость хуже чем у cygwin, но работает все быстрее. Частичное описание процесса сборки - на сайте llvm.

MSYS - дает нам "linux" shell, в котором можно запускать стандартные билд-скрипты. Именно по этому пути мы и пойдем.

Запускаем консоль MSYS, качаем исходники llvm, clang, compiler-rt (низкоуровневый системный код для сборки), распаковываем llvm в корень вашей папки с исходниками, clang - в llvm/tools, compiler-rt - в llvm/projects. Проверяем версию gcc - для llvm 3.2 подойдет gcc не новее 4.6.2 (с 4.7.2 у меня он сам себя не смог собрать, но и слишком старый тоже нельзя).

После этого создаем каталог для бинарников, например llvm/bin, переходим туда, и выполняем команду:

../configure --disable-docs --enable-optimized --enable-targets=x86 --prefix=/newclang

После завершения конфигурации - пишем make, и начнется сборка проекта. Когда закончится make - можем сделать make install, и наши скомпилированные бинарники запишутся в каталог newclang в корне файловой системы MSYS.

Далее - самосборка. Она нужна чтобы убедиться, что компилятор работает надежно, мы не упустили каких-либо проблем, и чтобы устранить одну переменную : "версия ксенокомпилятора". Перключаем систему на использование только что собранного clang для дальнейшей сборки им самого себя:

export CXX=/newclang/bin/clang++.exe
export CC=/newclang/bin/clang.exe

Создаем новый каталог для компиляции, снова запускаем там ../configure... и затем make. Но clang не соберется самим собой так просто, иначе в чем был бы смысл этой статьи?

Исправляем проблемы

Скорость работы Первое что бросается в глаза - собранный clang чудовищно тормозит, и это при релизной сборке! Даже простейший "clang++ --version" может выполнятся несколько секунд. Решение простое: нужно собирать его со статической линковкой, тогда все работает быстро, но ценой увеличенного размера бинарников (десятки мегабайт).

Export LDFLAGS=-static

Ошибка "Only alloca-wide stores can be split and recomposed" Это баг в llvm, который уже пофикшен в репозитории и войдет в 3.3. Но да, релиз clang 3.2 из-за этого не может собрать себя.

Нужно накатить на файл \lib\Transforms\Scalar\SROA.cpp фикс из ревизии svn 170270:

===================================================================
--- SROA.cpp	(revision 170269)
+++ SROA.cpp	(revision 170270)
@@ -2607,7 +2607,7 @@
              TD.getTypeStoreSizeInBits(V->getType()) &&
              "Non-byte-multiple bit width");
       assert(V->getType()->getIntegerBitWidth() ==
-             TD.getTypeSizeInBits(OldAI.getAllocatedType()) &&
+             TD.getTypeAllocSizeInBits(OldAI.getAllocatedType()) &&
              "Only alloca-wide stores can be split and recomposed");
       IntegerType *NarrowTy = Type::getIntNTy(SI.getContext(), Size * 8);
       V = extractInteger(TD, IRB, V, NarrowTy, BeginOffset,

Многопроцессорная сборка зависает Если вы используете make -j 8 для ускорения сборки - то да, mingw32 может под настроение намертво виснуть в середине сборки, по крайней мере на SSD (нет задержек на обращение к диску - больше шанс встретить какой-нибудь race condition). Решения я не нашел.

clang не может найти стандартные библиотеки Как мы помним, он использует стандартные библиотеки из gcc. Для того, чтобы он их нашел - они должны быть правильной версии, и лежать в ожидаемом clang-ом месте.

Не падайте со стула, пути для поиска файлов "захардкожены" в файле \tools\clang\lib\Frontend\InitHeaderSearch.cpp . Если у вас MinGW стоит не в папке по умолчанию, clang его точно не найдет. Затем, clang проверяет только некоторые версии gcc для поиска директории с заголовочными файлами, убедитесь что у вас стоит подходящая версия gcc.

Устанавливать пакеты нужной версии в MSYS можно так:

mingw-get install "gcc=4.6.*"
mingw-get install "g++=4.6.*"

Вот теперь clang сможет собрать сам себя, и вы получите свежий и быстрый, теплый и ламповый, собранный самим собой компилятор.