llvm常见问题解答
1.协议
1.为什么llvm源代码与其前端代码的授权协议不同？
c/c++前端代码基于gcc,从而必须以gpl分发。我们的目标是把llvm以更限制更弱的授权协议分发，尤其是这种协议：分发在修改代码基础上创建的工具时候，并不强迫他们也重新分发修改的部分。
译者注：据我的阅读llvm协议与bsd协议除了名字不同以外，没有什么区别。
2. 伊力诺依开源协议是真正的“开源”协议吗？
是的，伊力诺依开源协议是经过开源促进会(osi)认证的开源协议。
3. 我修改了llvm源代码，我可以重新分发修改的代码吗？
可以。修改源代码的分发必须保留版权声明，并且符合llvm协议种的“三个条件”
4. 我修改了llvm源代码，我是否可以重新分发它的二进制以及其它一些基于它的工具，而不重新分发源代码？
可以。正如上面第一个问题的解释，这是我们采用比gpl限制更弱的协议分发llvm的原因。
2.源代码
1. llvm是用什么语言写的？
所有的llvm工具与库都是使用c++写的，并且大量使用了stl.
2. llvm的可移植性怎么样？
llvm源代码应该在所有现代unix类操作系统上是可移植的。大部分的代码都是标准c++写就的，并使用了操作系统提供的一些服务来支持库。编译、测试llvm所需的工具已经移植到了大量的平台上了。
在一下领域也许存在一些移植问题：
gcc“前端”的代码不像llvm那么可移植，所以它在不支持的平台上也许不能很好的编译。
llvm编译系统很大程度上依赖于像sh,sed之类的unix shell工具.移植到没有这些工具的系统（比如MAC OS 9,Plan 9）将会需要更多努力。
3.编译问题
1. 当我运行configure脚本，它找到了错误的c编译器.
除非找到了分别为c/c++设置的路径cc/cxx,configure脚本首先试图定位gcc,然后是cc。
如果configure脚本找到了错误的编译器，或者调整PATH环境变量，或者显示地设置cc/cxx
2.
The configure script finds the right C compiler, but it uses the LLVM linker from a previous build. What do I do?
The configure script uses the PATH to find executables, so if it's grabbing the wrong linker/assembler/etc, there are two ways to fix it:
Adjust your PATH environment variable so that the correct program appears first in the PATH. This may work, but may not be convenient when you want them first in your path for other work.
Run configure with an alternative PATH that is correct. In a Borne compatible shell, the syntax would be:
% PATH=[the path without the bad program] ./configure ...
This is still somewhat inconvenient, but it allows configure to do its work without having to adjust your PATH permanently.
3.当创建一个动态库的时候，我得到一个奇怪的GLIBC错误
在一起操作系统（即linux）上，如果gcc是使用--disable-shared选项编译的，libtool就不能正常工作。作为一个补救措施，你可以安装一个激活了共享库的版本的gcc。
4.我已经从svn更新了我的源代码树，不过我编译时候它试图去使用一个不不存在的文件/路径
你需要在你的对象目录重新运行configure 脚本.新的Makefile被加到源代码树以后，请把他们复制到对象树里面。
5.我已经修改了我地源代码树里面地Makefile文件，不过我地编译过程仍然使用旧的版本，我应该怎么办？
如果Makefile文件存在于你的对象树，你只需在你对象树的定级目录运行如下命令：
% ./config.status
If the Makefile is new, you will have to modify the configure script to copy it over.
6.我已经更新llvm到一个新版本了，我得到一些奇怪的编译错误。
有时候，源代码的变更会改变编译系统的工作方式。libtool,autoconf,以及头文件依赖关系的变更容易导致这种问题。最好试着移走旧的文件，并重新编译。多数情况下，这样就可以解决问题了。只需要在编译失败的目录，输入make clean命令，输入make命令即可。
阅读(2412) | 评论(0) | 转发(0) |
