LLVM is an open-source compiler infrastructure. LLVM was started in 2000, and has been extensively used and modified by Apple since 2005. Clang is a C, C++, Objective-C, and Objective-C++ compiler that works with the LLVM system. Clang was started in 2007 by Apple, and since then Google and Intel have become involved in its continued development.<\/p>\n
Clang’s developers claim that compared to GCC, it compiles faster, uses less memory, gives more user friendly diagnostics during compilation, and is compatible with GCC.<\/p>\n
CentOS follows the development of Red Hat Enterprise Linux (RHEL). RHEL strives to be a stable server platform, which means it does not rush to include the latest versions of everything.<\/p>\n
As of the writing of this article, CentOS 6 officially distributes LLVM & Clang v3.4.2. However, Clang v3.6 has been released.<\/p>\n
The official suggestion is if you need a more recent version of LLVM & Clang, you should consider a different UNIX distribution which is more focused on supporting the latest versions of software packages.<\/p>\n
Fortunately, you are able to install a more recent version LLVM & Clang GCC on CentOS. This deviates from purely using the officially distributed software, but sometimes you may feel like you have little choice.<\/p>\n
This article describes how to install the CentOS 6 officially supported version of LLVM & Clang, and how to install a newer version. This article assumes you have a freshly installed CentOS 6 VPS, however you can certainly follow the instructions on a VPS you have already been using.<\/p>\n
Clang is largely independent from GCC, but as of the writing of this article, Clang still uses several shared libraries installed by GCC (namely,\u00a0 Additionally, building a newer version of LLVM & Clang from source requires G++ v4.7+, which you can only get on CentOS 6 by installing it by source.<\/p>\n If you run all of the steps below, you’ll wind up with 2 versions of GCC and 2 versions of LLVM & Clang. This includes an officially supported binary older version and a newer version from source for each program. However, there’s no need to run all the steps below. You can decide whether you want the officially supported binary older version of LLVM & Clang, or the newer version from source, and run whichever section of instructions fits your decision.<\/p>\n To build LLVM & Clang by source on CentOS, you have to have GCC v4.7 or above. CentOS 6 does not have this high of a version in yum, so you first have to install a more recent GCC from source.<\/p>\n You now have your newer LLVM & Clang in\u00a0crtbegin.o<\/code>,\u00a0
gcc<\/code>, and\u00a0
gcc_s<\/code>). If you install LLVM & Clang on CentOS 6, you won’t be able to compile anything if you don’t also have GCC on your system for these shared libraries. Ideally, yum would have a package dependency for clang of gcc and gcc-c++, but as of the writing of this article, yum is unaware of the dependency.<\/p>\n
Install an officially supported (older) version of LLVM & Clang<\/h3>\n
\n
sudo yum install clang\r\n --- This will bring in llvm as a dependency\r\n<\/code><\/pre>\n<\/li>\n
clang --version\r\n May say: clang version 3.4.2 (tags\/RELEASE_34\/dot2-final)\r\nwhich clang\r\n \/usr\/bin\/clang\r\ngcc --version\r\n May say: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)\r\ng++ --version\r\n May say: g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)\r\nwhich gcc\r\n \/usr\/bin\/gcc\r\nwhich g++\r\n \/usr\/bin\/g++\r\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
Install a newer version of LLVM & Clang from source<\/h3>\n
\n
sudo yum install cmake\r\n<\/code><\/pre>\n<\/li>\n
mkdir ~\/sourceInstallations\r\ncd ~\/sourceInstallations\r\nwget https:\/\/www.python.org\/ftp\/python\/2.7.9\/Python-2.7.9.tgz\r\ntar -xvf Python-2.7.9.tgz\r\ncd Python-2.7.9\r\n.\/configure && make && sudo make install\r\n<\/code><\/pre>\n<\/li>\n
svn ls http:\/\/llvm.org\/svn\/llvm-project\/llvm\/tags | grep RELEASE\r\n RELEASE_1\/\r\n ...\r\n RELEASE_352\/\r\n RELEASE_360\/\r\n RELEASE_361\/\r\nsvn ls http:\/\/llvm.org\/svn\/llvm-project\/llvm\/tags\/RELEASE_361\r\n rc1\/\r\n --- At this time, there is no final, just a release candidate. You could certainly use a release candidate, but this article will show how to use a final release.\r\nsvn ls http:\/\/llvm.org\/svn\/llvm-project\/llvm\/tags\/RELEASE_360\r\n final\/\r\n rc1\/\r\n rc2\/\r\n rc3\/\r\n rc4\/\r\n<\/code><\/pre>\n<\/li>\n
RELEASE_360\/<\/code>\u00a0and will download the sources into\u00a0
~\/sourceInstallations\/llvm_RELEASE_360\/<\/code>\u00a0— You will have to substitute the proper tag to fit future versions. The directories below of\u00a0
compiler-rt<\/code>,\u00a0
libcxx<\/code>, and\u00a0
libcxxabi<\/code>\u00a0are not absolutely necessary, but contain some of the features that LLVM & Clang have that GCC doesn’t, so are included in this article. There are other LLVM “sub-projects” you could choose to use, such as dragonegg, LLDB, OpenMB, vmkit, polly, libclc, klee, SAFECode, and lld. You can read about those on the\u00a0LLVM website<\/a>.\n
cd ~\/sourceInstallations\r\nsvn co http:\/\/llvm.org\/svn\/llvm-project\/llvm\/tags\/RELEASE_360\/final llvm_RELEASE_360\r\ncd llvm_RELEASE_360\/tools\r\nsvn co http:\/\/llvm.org\/svn\/llvm-project\/cfe\/tags\/RELEASE_360\/final clang\r\ncd ..\/projects\r\nsvn co http:\/\/llvm.org\/svn\/llvm-project\/compiler-rt\/tags\/RELEASE_360\/final compiler-rt\r\nsvn co http:\/\/llvm.org\/svn\/llvm-project\/libcxx\/tags\/RELEASE_360\/final libcxx\r\nsvn co http:\/\/llvm.org\/svn\/llvm-project\/libcxxabi\/tags\/RELEASE_360\/final libcxxabi\r\ncd ..\r\nsvn update\r\n At revision X.\r\n --- Hopefully this outputs one line saying \"At revision X\", but numbers instead of \"X\". If it downloads more source files, a new revision was released while you were downloading the source code. This is highly unlikely unless you're using trunk (the most up to date, maybe unstable code.) But, if this happens, perform a svn update in the tools\/clang, projects\/compiler-rt, projects\/libcxx, projects\/libcxxabi, and again ~\/sourceInstallations\/llvm_RELEASE_360, until you are fully up to date.\r\n<\/code><\/pre>\n<\/li>\n
mkdir ..\/llvm_RELEASE_360_build\r\ncd ..\/llvm_RELEASE_360_build\r\ncmake -G \"Unix Makefiles\" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=\/usr\/local\/bin\/gcc -DCMAKE_CXX_COMPILER=\/usr\/local\/bin\/g++ ..\/llvm_RELEASE_360 && make && sudo make install && echo success\r\n --- If your VPS has multiple cores, you can speed up the build by changing the middle part\r\n --- of this line from \"&& make &&\" to \"&& make -j <number of cores> &&\".\r\n --- You can see the number of cores your VPS has by running \"nproc\"\r\n --- If you omit -DCMAKE_BUILD_TYPE=Release, the build defaults to debug. This is great if you need to debug LLVM & Clang itself, but slows down compilation of your end programs considerably.\r\n --- If you omit the references to gcc and g++, it will default to using the older binary versions in \/usr\/bin\/, and will not compile.\r\n<\/code><\/pre>\n<\/li>\n
clang --version\r\n May say: clang version 3.6.0 (tags\/RELEASE_360\/final 237229)\r\nclang++ --version\r\n May say: clang version 3.6.0 (tags\/RELEASE_360\/final 237229)\r\nwhich clang\r\n \/usr\/local\/bin\/clang\r\nwhich clang++\r\n \/usr\/local\/bin\/clang++\r\n<\/code><\/pre>\n<\/li>\n
echo \"\/usr\/local\/lib\" > usrLocalLib.conf\r\nsudo mv usrLocalLib.conf \/etc\/ld.so.conf.d\/\r\nsudo ldconfig\r\n --- This may say a file or two \"is not an ELF file - it has the wrong magic bytes at the start.\"\r\n --- You may ignore this message. It is silent about the work it successfully completed.\r\n<\/code><\/pre>\n<\/li>\n
mkdir ~\/code\r\ncd ~\/code\r\nCreate a file main.cpp that says:\r\n #include <iostream>\r\n using namespace std;\r\n int main() {\r\n cout << \"Hello world!\" << endl;\r\n return 0;\r\n }\r\n--- One way to create this file is to run \"vi main.cpp\", hitting \"i\" to enter insert mode,\r\n--- typing the above file, hitting ESC, and hitting \"ZZ\" to save.\r\nclang++ main.cpp -o main\r\n.\/main\r\n Hello World!\r\nclang++ -stdlib=libc++ -lc++abi main.cpp -o main\r\n --- This uses Clang's libc++ and libc++abi, instead of the GNU stdlibc++ and stdlibc++abi\r\n.\/main\r\n Hello world!\r\n<\/code><\/pre>\n<\/li>\n
You could set LLVM & Clang to be your system's default C and C++ compiler by running:\r\n echo \"export CC=\/usr\/local\/bin\/gcc\" >> ~\/.bashrc\r\n echo \"export CXX=\/usr\/local\/bin\/g++\" >> ~\/.bashrc\r\n source ~\/.bashrc\r\nOnce and a while there is a difference between Clang and GCC, but it's becoming more and more rare. To be more conservative, you could specify in your code's buildsystem to use LLVM & Clang, but otherwise leave your system's default to the source build of GCC.\r\n<\/code><\/pre>\n<\/li>\n
~\/sourceInstallations<\/code>\u00a0folder will be taking up around 11GB of disk space. It’s probably wise to keep the folders, as there are optional configuration options you may need to use at some point in the future, and it would be faster to have a lot already done. And, as mentioned above, there are additional “sub-projects” you can add to LLVM & Clang. Also, the build process makes logs that you can later check and work from if something goes wrong. But, after running “sudo make install” earlier, your installed LLVM & Clang isn’t depending on anything in this directory, and space can be at a premium, so you can do this step and reclaim the 11GB.\n
cd ~\/\r\nrm -rf sourceInstallations\r\n--- Again, if you can spare the space, you may someday be happy to have left it there.\r\n<\/code><\/pre>\n<\/li>\n<\/ol>\n
\/usr\/local\/bin<\/code>, your newer 64-bit LLVM & Clang libs in\u00a0
\/usr\/local\/lib<\/code>, and your newer LLVM & Clang include files in\u00a0
\/usr\/local\/include<\/code>.<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","format":"standard","manualknowledgebasecat":[231,242],"manual_kb_tag":[503],"_links":{"self":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/3023"}],"collection":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb"}],"about":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/types\/manual_kb"}],"author":[{"embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/comments?post=3023"}],"version-history":[{"count":2,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/3023\/revisions"}],"predecessor-version":[{"id":3025,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/3023\/revisions\/3025"}],"wp:attachment":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/media?parent=3023"}],"wp:term":[{"taxonomy":"manualknowledgebasecat","embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manualknowledgebasecat?post=3023"},{"taxonomy":"manual_kb_tag","embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb_tag?post=3023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}