由于之前整理的服务器框架已经完成了，就需要用各种静态分析工具跑一遍。原来的llvm+clang的编译脚本是从GCC那个脚本copy过来然后改的，使用的时候各种问题。所以干醋重新折腾一遍，重写了。
之前的脚本，每次升级版本都要折腾下，一开始是编译的默认静态库巨大无比，后来改成动态库后一会儿好一会儿不好。 目测3.9.0版本的问题是开启动态库的编译模式以后有些子工程还是静态库，并且会漏掉加-fPIC，即便我在cmake的选项里加了也没用。 而且有时候是用gcc编译正常，用clang自举编译的时候失败。 然后每次测试一次都要花费巨量的时间，巨慢无比。我只是编译出来玩+当某些工具使用啊喂。要不要这么折腾我啊喂。
所以索性重写了，然后这回干脆不适用原来的动态库命令了，llvm的文档里说那个命令仅供llvm的developer。然后有新的选项是把编译出来的各种.a都动态链接到一起（我试了下保留Debug信息的话这个libLLVM.so有900MB）。所以干脆不保留Debug信息了。 然而之前发现的make install的时候的python目录的bug依然存在，所以就还是保留了那个bug的处理。
也是醉，现在的脚本终于第一次编译个自举编译又都OK了，然后建议的额外的编译flags也改成了使用llvm-config来显示。并且新的脚本的编译速度也比以前大幅提升了。
写这个脚本的时候发现过一些问题，llvm套件编译的时候要耗费巨量的内存。一开始我是用CPU核心数除2的多进程编译的，后来发现内存扛不住。加交换区的话有很慢，所以现在的策略是先4进程编译，失败了再2进程，再失败1进程，再失败就真的是失败了。 之前观测得是2进程的时候要消耗大约12GB内存。
另外一开始我是RelWithDebInfo编译的，也就是带了调试符号。后来发现，这么编译的话编出来的各种静态库和动态库都巨大无比，大约一起十多个GB。 然后用这个带调试信息的clang自举编译的时候又巨慢无比，而且内存有彪上去了。我编译跑了一下午也没跑完。所以索性改成Release编译了，去除了调试符号。 现在编译速度比较正常了，编译出的文件大小已比较正常了。
再就是一些组件的细节调整了下，编译lldb的时候会检查下依赖的库有没有，没有就跳过。默认都睡编译lldb和lld了。 openmp我不用所以没加进去，反正加一下也不麻烦。dragonegg的依赖过于奇葩，我也没加进去了，这也是个折腾的主儿，而且真的需要用gcc的前端+llvm的后端吗？有需要的人自己加吧。
希望不要下次版本有各种问题吧，唉。次版本的编译脚本位于: https://github.com/owent-utils/bash-shell/tree/master/LLVM%26Clang%20Installer/3.9
clang -O0 -g -ggdb -std=c++11 -stdlib=libstdc++ -lstdc++ [源文件…]
clang++ -O0 -g -ggdb -std=c++11 -stdlib=libstdc++ [源文件…]
clang -O0 -g -ggdb -std=c++11 -stdlib=libc++ -lc++ -lc++abi [源文件…]
clang -O0 -g -ggdb -std=c++14 -stdlib=libc++ -lc++ -lc++abi [源文件…]
clang++ -O0 -g -ggdb -std=c++11 -stdlib=libc++ -lc++abi [源文件…]
clang++ -O0 -g -ggdb -std=c++14 -stdlib=libc++ -lc++abi [源文件…]
其他选项参见: llvm-config –cflags ; llvm-config –cxxflags ; llvm-config –ldflags
编译安装 LLVM + Clang 3.9
CentOS 7.1
详情参见 llvm官网
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。