There is incompatibility about python site-packages on my 64-bit RedHat Enterprise Linux 6.3, so lldb can not run "script" command properly because it can not search python libraries. Problem 1: $(framework_python_dir) is evaluated as "....../lib64/python2.6/site-packages" in shell script "finish-swig-Python-LLDB.sh" and later a soft link named "_lldb.so" pointing to ../../../liblldb.so is created. Since lldb puts liblldb.so into "lib", this soft link is broken. The correct soft link might be "../../../../lib/liblldb.so". Problem 2: lldb always install python into system path /usr/lib64/python2.6/site-packages. If we do not has the authority, installment will fail. Problem 3 (possible): Assume we change finish-swig-Python-LLDB.sh to install python2.6/site-packages into $(LLVM_Install_Path)/lib64 (which is natual in finish-swig-Python-LLDB.sh), lldb still can not find python dependencies since Host::GetLLDBPath() in lldb/source/Host/common/Host.cpp detects g_lldb_python_dir at "....../lib/python". I believe current implementation does not distinguish 64-bit and 32-bit linux OSes. In a word, since python is defaulted to be installed at "/usr/lib64/......" instead of "/usr/lib/......" on my 64-bit RHEL, lldb can not run "script".
I hit similar issue when building swift on Fedora 23 x86_64: https://github.com/apple/swift
Hmm, I am interested in finding out if this is different between RHEL 6 and 7. I specifically did work to get RHEL 7 (well, CentOS 7 specifically) test suite to run roughly 2 months ago. Seems like either: (1) there is a diff on CentOS 7 to RHEL 7 (which I can check), (2) RHEL 6 and 7 differ on the proper handling of that as far as the fix I made, or (3) recent changes in the finishing script broke what I had changed there for RHEL. On a related note, we will ultimately need to address 'extra override modules' (right now, only the readline.so module we use to prevent a conflict between libedit usage in lldb from stock python readline module, which brings both readline and libedit into the same process, where dynamic linking issues on the readline compatibility of libedit cause segfaults). That current layout is not particularly good. This will require some work to straight out to figure out the right solution that works on both Ubuntu and RHEL.
Hmm, not sure why that posted twice!
This bug is also present on the swift-lldb build on both fedora 22 and fedora 23.
I regularly run the test suite on CentOS 7, and used this patch to fix the python symlinks: http://reviews.llvm.org/D19067 You will need to make sure that LLVM_LIBDIR_SUFFIX matches the libdir of python2.7/site-packages. (On CentOS 7, this will be LLVM_LIBDIR_SUFFIX=64, to match lib64).
I have the patch mentioned in comment #6, but I still have a problem here -- my build fails like: CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file): file INSTALL cannot find "/home/tromey/Rust/rust-2/build/x86_64-unknown-linux-gnu/llvm/build/lib/python2.7". Call Stack (most recent call first): tools/lldb/cmake_install.cmake:51 (include) tools/cmake_install.cmake:49 (include) cmake_install.cmake:65 (include) Now, I suppose setting LLVM_LIBDIR_SUFFIX=64 would fix this; but I don't understand why this is needed. Why can't cmake figure this out on its own, since it already seems to in some cases?
Created attachment 20544 [details] sample patch Here's the patch I came up with. It seems to work ok but I don't really know :)