<div dir="ltr">The one with "default" in the name just controls the value if you don't specify it on the command line. Below that though you see where it sets the real variable, which if I remember correctly is called <span style="font-family:arial,sans-serif;font-size:13px">LLDB_ENABLE_</span><u style="font-family:arial,sans-serif;font-size:13px"></u><span style="font-family:arial,sans-serif;font-size:13px">PYTHON</span><span style="font-family:arial,sans-serif;font-size:13px">_SCRIPTS_SWIG_API_</span><u style="font-family:arial,sans-serif;font-size:13px"></u><span style="font-family:arial,sans-serif;font-size:13px">GENERATION. You can set this from the command line by running cmake -D</span><span style="font-size:13px;font-family:arial,sans-serif">LLDB_ENABLE_</span><u style="font-size:13px;font-family:arial,sans-serif"></u><span style="font-size:13px;font-family:arial,sans-serif">PYTHON</span><span style="font-size:13px;font-family:arial,sans-serif">_SCRIPTS_SWIG_API_</span><u style="font-size:13px;font-family:arial,sans-serif"></u><span style="font-size:13px;font-family:arial,sans-serif">GENERATION=1</span><div>
<font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Regarding your other question, in scripts\CMakeLists.txt you'll see these two lines:</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif"><div><span class="" style="white-space:pre"> </span> COMMAND env PYTHON_EXECUTABLE=${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/build-swig-wrapper-classes.sh ${LLDB_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR} -m</div>
<div><span class="" style="white-space:pre"> </span> COMMAND env PYTHON_EXECUTABLE=${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/finish-swig-wrapper-classes.sh ${LLDB_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR} -m</div>
<div><br></div><div>Change them to:</div><div><br></div><div><div><span class="" style="white-space:pre"> </span> COMMAND env PYTHON_EXECUTABLE=${PYTHON_EXECUTABLE} sh -x ${CMAKE_CURRENT_SOURCE_DIR}/build-swig-wrapper-classes.sh ${LLDB_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR} -m</div>
<div><span class="" style="white-space:pre"> </span> COMMAND env PYTHON_EXECUTABLE=${PYTHON_EXECUTABLE} sh -x ${CMAKE_CURRENT_SOURCE_DIR}/finish-swig-wrapper-classes.sh ${LLDB_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR} -m</div>
</div></font><div class="gmail_extra"><br></div><div class="gmail_extra">(I think it's -x anyway, it's whatever option prints out the list of commands that the shell script ultimately runs). This way when you run CMake, it will print out each command that the shell script runs, and you can use this to isolate which step might be failing.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If you instead use the python swig generator by setting the first variable, you can modify that command line to pass -d to the python scripts, and it will cause them to print out more information as well, such as where they're inputting / outputting files to and from.<br>
<br><div class="gmail_quote">On Mon, Jul 21, 2014 at 10:01 PM, Matthew Gardiner <span dir="ltr"><<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">Todd Fiala wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
I'll do a configure/make build on Ubuntu 14.04 x86_64 later today<br>
to see if I'm getting the same results on configure/make - there<br>
has been some changes in python handling more recently, generally<br>
to support Windows builds, but we may have unintentionally<br>
introduced that via those changes. At least that way we can see<br>
if its consistent with configure/make or if it might just be<br>
specific to Fedora Core.<br>
<br>
<br>
Okay, I tried a configure/make on top of tree on Ubuntu 14.04 x86_64. I did not get the lib64 dir, so this seems to be a diff in the flow between the Ubuntu and FC build.<br>
</blockquote>
<br></div>
Ok, thanks for confirming the difference between your ubuntu and my FC experience.<br>
<br>
By the way I've just opened llvm/tools/lldb/CMakeLists.txt<br>
<br>
if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )<br>
set(LLDB_DEFAULT_DISABLE_<u></u>PYTHON 1)<br>
set(LLDB_DEFAULT_DISABLE_<u></u>CURSES 1)<br>
if (LLDB_DISABLE_PYTHON)<br>
set(LLDB_DEFAULT_ENABLE_<u></u>PYTHON_SCRIPTS_SWIG_API_<u></u>GENERATION 0)<br>
else()<br>
set(LLDB_DEFAULT_ENABLE_<u></u>PYTHON_SCRIPTS_SWIG_API_<u></u>GENERATION 1)<br>
endif()<br>
else()<br>
set(LLDB_DEFAULT_DISABLE_<u></u>PYTHON 0)<br>
set(LLDB_DEFAULT_DISABLE_<u></u>CURSES 0)<br>
set(LLDB_DEFAULT_ENABLE_<u></u>PYTHON_SCRIPTS_SWIG_API_<u></u>GENERATION 0)<br>
endif()<br>
<br>
I'm guessing<br>
<br>
set(LLDB_DEFAULT_ENABLE_<u></u>PYTHON_SCRIPTS_SWIG_API_<u></u>GENERATION 0) means:<br>
<br>
"In non-windows we use shell scripts not python to run swig".<br>
<br>
Anyway, I guess this is the CMake variable Zachary meant.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Incidentally, I am having trouble running tests with configure/make. Might just be my setup or configure invocation, but I'll get around to tracking that down here at some point. For now, I'd definitely recommend going the cmake/ninja route for testing.<br>
</blockquote>
<br></div>
Yeah, agreed, at least till we get this figured out.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
Thanks for identifying that!<br>
<br>
-Todd<br>
<br>
<br>
<br>
On Mon, Jul 21, 2014 at 6:51 AM, Matthew Gardiner <<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>>> wrote:<br>
<br>
Todd,<br>
<br>
I've since discovered that the cmake/ninja build system also<br>
results in a lib and lib64 directory, with the liblldb.so and<br>
other .sos in the lib folder but the<br>
python2.7/site-packages/lldb under lib64. (In fact with cmake<br>
build I see no python2.7 folder at all under lib, it's all<br>
under lib64).<br>
<br>
So Todd, focusing back on autoconf/make builds, after doing<br>
the ./configure && make in the sibling build directory, do you<br>
see for your linux 64-bit builds the<br>
python2.7/site-packages/lldb under the lib64 sub-folder and<br>
the lldb/llvm .sos under the lib64 sub-folder?<br>
<br>
How do you get this to work:<br>
<br>
<br>
tfiala@tfiala2:/mnt/ssd/work/<u></u>macosx.sync/mbp-svn/build-<u></u>debug/lib$<br>
PYTHONPATH=`pwd`/python2.7/<u></u>site-packages python<br>
Python 2.7.6 (default, Mar 22 2014, 22:59:56)<br>
[GCC 4.8.2] on linux2<br>
Type "help", "copyright", "credits" or "license" for more<br>
information.<br>
>>> import lldb<br>
>>> dir(lldb)<br>
<br>
Do you run another script or make target after doing the basic<br>
llvm/lldb make? That is to move python2.7/site-packages/lldb<br>
underneath lib. I think that's what I'd have to do on my<br>
system, since after the basic make my lib and lib64<br>
directories have the following contents:<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib/python2.7/site-<u></u>packages<br>
<br>
$ ls -al<br>
total 32<br>
drwxrwxr-x 2 mg11 mg11 4096 Jul 21 14:40 .<br>
drwxrwxr-x 3 mg11 mg11 4096 Jul 21 14:40 ..<br>
-rwxr-xr-x 1 mg11 mg11 21795 Jul 21 14:40 readline.so<br>
<br>
$ cd ../../../lib64/python2.7/site-<u></u>packages/<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib64/python2.7/site-<u></u>packages<br>
<br>
$ ls -al<br>
total 12<br>
drwxrwxr-x 3 mg11 mg11 4096 Jul 21 14:42 .<br>
drwxrwxr-x 3 mg11 mg11 4096 Jul 21 14:42 ..<br>
drwxrwxr-x 5 mg11 mg11 4096 Jul 21 14:42 lldb<br>
<br>
<br>
Any ideas?<br>
Matt<br>
<br>
<br>
Matthew Gardiner wrote:<br>
<br>
Hi Todd,<br>
<br>
Thanks for taking the time to come up with these tips.<br>
First off my distro is Fedora Core 20 64-bit. So to<br>
further my investigation I blew away all the sources, and<br>
did svn co llvm, (lldb clang into llvm/tools), made the<br>
sibling build dir, then did:<br>
<br>
~/src/p4play/build<br>
$ ../llvm/configure --enable-targets=x86_64<br>
--enable-shared --enable-cxx11 --prefix=`pwd`/../install<br>
&& make -j 8<br>
<br>
After the successful build I do ldd. Basically lld finds<br>
all dependencies for liblldb.so...<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib<br>
$ ldd liblldb.so<br>
linux-vdso.so.1 => (0x00007fffa61fe000)<br></div></div><div class="">
<a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a> <<a href="http://libLLVM-3.5svn.so" target="_blank">http://libLLVM-3.5svn.so</a>> =><br>
/home/mg11/src/p4play/build/<u></u>Debug+Asserts/lib/./<a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.<u></u>5svn.so</a><br></div>
<<a href="http://libLLVM-3.5svn.so" target="_blank">http://libLLVM-3.5svn.so</a>> (0x00007f2e53405000)<div><div class="h5"><br>
libpthread.so.0 => /lib64/libpthread.so.0<br>
(0x00007f2e531cc000)<br>
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2e52fc8000)<br>
libutil.so.1 => /lib64/libutil.so.1 (0x00007f2e52dc5000)<br>
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0<br>
(0x00007f2e529fe000)<br>
librt.so.1 => /lib64/librt.so.1 (0x00007f2e527f6000)<br>
libedit.so.0 => /lib64/libedit.so.0 (0x00007f2e525ba000)<br>
libncurses.so.5 => /lib64/libncurses.so.5<br>
(0x00007f2e52392000)<br>
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2e52168000)<br>
libpanel.so.5 => /lib64/libpanel.so.5 (0x00007f2e51f64000)<br>
libz.so.1 => /lib64/libz.so.1 (0x00007f2e51d4d000)<br>
libm.so.6 => /lib64/libm.so.6 (0x00007f2e51a46000)<br>
libstdc++.so.6 => /lib64/libstdc++.so.6<br>
(0x00007f2e5173e000)<br>
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2e51527000)<br>
libc.so.6 => /lib64/libc.so.6 (0x00007f2e51168000)<br>
/lib64/ld-linux-x86-64.so.2 (0x0000003675a00000)<br>
<br>
However, regarding python loading the lldb bindings I see<br>
my build/Debug+Asserts has a lib and a lib64 folder.<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts<br>
$ ls<br>
bin lib lib64<br>
<br>
If I try to import lldb when I have "lib" as my PYTHONPATH<br>
i.e.<br>
<br>
~/src/main/build/Debug+<u></u>Asserts/lib<br>
$ PYTHONPATH=`pwd`/python2.7/<u></u>site-packages/ python<br>
>>> import lldb<br>
Traceback (most recent call last):<br>
File "<stdin>", line 1, in <module><br>
ImportError: No module named lldb<br>
>>><br>
<br>
This is not surprising, since<br>
~/src/main/build/Debug+<u></u>Asserts/lib/python2.7/site-<u></u>packages/ only<br>
contains readline.so.<br>
So I cd to lib64. This looks more promising since there is<br>
a lldb folder below site-packages. So now I do "import<br>
lldb" with "lib64" instead:<br>
<br>
~/src/main/build/Debug+<u></u>Asserts/lib64<br>
$ PYTHONPATH=`pwd`/lib64/<u></u>python2.7/site-packages/ python<br>
Python 2.7.5 (default, Feb 19 2014, 13:47:28)<br>
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2<br>
Type "help", "copyright", "credits" or "license" for more<br>
information.<br>
>>> import lldb<br>
Traceback (most recent call last):<br>
File "<stdin>", line 1, in <module><br>
File<br>
"/home/mg11/src/main/build/<u></u>Debug+Asserts/lib64/python2.7/<u></u>site-packages/lldb/__init__.<u></u>py",<br>
line 52, in <module><br>
_lldb = swig_import_helper()<br>
File<br>
"/home/mg11/src/main/build/<u></u>Debug+Asserts/lib64/python2.7/<u></u>site-packages/lldb/__init__.<u></u>py",<br>
line 44, in swig_import_helper<br>
import _lldb<br>
ImportError: No module named _lldb<br>
>>><br>
<br>
So cd to<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib64/python2.7/site-<u></u>packages/lldb,<br>
and list:<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib64/python2.7/site-<u></u>packages/lldb<br>
$ ls -l<br>
total 1196<br>
-rw-rw-r-- 1 mg11 mg11 3905 Jul 21 08:25<br>
embedded_interpreter.py<br>
drwxrwxr-x 3 mg11 mg11 4096 Jul 21 08:25 formatters<br>
-rw-rw-r-- 1 mg11 mg11 495675 Jul 21 08:25 __init__.py<br>
-rw-rw-r-- 1 mg11 mg11 708200 Jul 21 09:09 __init__.pyc<br>
lrwxrwxrwx 1 mg11 mg11 19 Jul 21 08:25 _lldb.so -><br>
../../../liblldb.so !BROKEN SYMLINK!<br>
drwxrwxr-x 2 mg11 mg11 4096 Jul 21 08:25 runtime<br>
drwxrwxr-x 2 mg11 mg11 4096 Jul 21 08:25 utils<br>
<br>
_lldb.so is broken above as the link above assumes<br>
liblldb.so is just 3 dirs back. However, it isn't -<br>
because it's not in lib64, *it's in lib*. So it looks like<br>
things are getting a bit mashed up due to 32-bit/64-bit<br>
directory issues. If I copy the .so files from lib to<br>
lib64, then it fixes my broken sym-link issue. And I<br>
progress a little further.<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib64<br>
$ PYTHONPATH=`pwd`/python2.7/<u></u>site-packages python<br>
Python 2.7.5 (default, Feb 19 2014, 13:47:28)<br>
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2<br>
Type "help", "copyright", "credits" or "license" for more<br>
information.<br>
>>> import lldb<br>
Traceback (most recent call last):<br>
File "<stdin>", line 1, in <module><br>
File<br>
"/home/mg11/src/p4play/build/<u></u>Debug+Asserts/lib64/python2.7/<u></u>site-packages/lldb/__init__.<u></u>py",<br>
line 52, in <module><br>
_lldb = swig_import_helper()<br>
File<br>
"/home/mg11/src/p4play/build/<u></u>Debug+Asserts/lib64/python2.7/<u></u>site-packages/lldb/__init__.<u></u>py",<br>
line 48, in swig_import_helper<br>
_mod = imp.load_module('_lldb', fp, pathname, description)<br></div></div>
ImportError: <a href="http://libLLVM-3.5svn.so" target="_blank">libLLVM-3.5svn.so</a> <<a href="http://libLLVM-3.5svn.so" target="_blank">http://libLLVM-3.5svn.so</a>>:<div><div class="h5"><br>
cannot open shared object file: No such file or directory<br>
>>><br>
<br>
So now I push the location of these .sos into my<br>
environment with LD_LIBRARY_PATH. Finally lldb imports!<br>
<br>
~/src/p4play/build/Debug+<u></u>Asserts/lib64<br>
$ LD_LIBRARY_PATH=.<br>
PYTHONPATH=`pwd`/python2.7/<u></u>site-packages python<br>
Python 2.7.5 (default, Feb 19 2014, 13:47:28)<br>
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2<br>
Type "help", "copyright", "credits" or "license" for more<br>
information.<br>
>>> import lldb<br>
>>> dir(lldb)<br>
['INT32_MAX', 'LLDB_ARCH_DEFAULT',<br>
... lots more ...<br>
>>><br>
<br>
So, I think the crux of the problem I'm seeing here is<br>
that on a 64-bit linux build (using autoconf/make) we get<br>
the binaries distributed around the lib and lib64<br>
sub-folders without adequate coordination with the test<br>
tools. I'll retry now with cmake/ninja and see if my<br>
experience differs.<br>
<br>
Matt<br>
<br>
<br>
<br>
Todd Fiala wrote:<br>
<br>
<br>
Hey Matt,<br>
<br>
(Adding back the list since these are general<br>
troubleshooting tips for getting tests running).<br>
<br>
Sorry you’re having so much trouble with this!<br>
<br>
Ok so a few things to troubleshoot:<br>
<br>
Regardless of the build system used, go to the build<br>
output’s lib dir. Do this command:<br>
ldd liblldb.so<br>
<br>
That will spit out all the shared libraries that your<br>
liblldb.so is trying to link against. The python<br>
message your seeing will happen if python can’t find<br>
the lldb module (as the message suggests and you were<br>
tracing down), /or/ if it can find it but fails to<br>
load it (which is often the case - something cannot be<br>
found when the liblldb.so tries to load as a<br>
consequence of the lldb python module trying to load).<br>
<br>
You should see something that looks roughly like this:<br>
<br>
|tfiala@tfiala2:/mnt/ssd/work/<u></u>macosx.sync/mbp-svn/build-<u></u>debug/lib$<br>
ldd liblldb.so<br>
linux-vdso.so.1 => (0x00007fffe9dfe000)<br>
libstdc++.so.6 =><br>
/usr/lib/x86_64-linux-gnu/<u></u>libstdc++.so.6<br>
(0x00007f6357e71000)<br>
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.<u></u>6<br>
(0x00007f6357b6b000)<br>
libedit.so.2 =><br>
/usr/lib/x86_64-linux-gnu/<u></u>libedit.so.2<br>
(0x00007f635793a000)<br>
libpanel.so.5 =><br>
/usr/lib/x86_64-linux-gnu/<u></u>libpanel.so.5<br>
(0x00007f6357736000)<br>
libncurses.so.5 =><br>
/lib/x86_64-linux-gnu/<u></u>libncurses.so.5 (0x00007f6357513000)<br>
libtinfo.so.5 =><br>
/lib/x86_64-linux-gnu/<u></u>libtinfo.so.5 (0x00007f63572e9000)<br>
libpython2.7.so.1.0 =><br>
/usr/lib/x86_64-linux-gnu/<u></u>libpython2.7.so.1.0<br>
(0x00007f6356d82000)<br>
librt.so.1 =><br>
/lib/x86_64-linux-gnu/librt.<u></u>so.1 (0x00007f6356b7a000)<br>
libdl.so.2 =><br>
/lib/x86_64-linux-gnu/libdl.<u></u>so.2 (0x00007f6356975000)<br>
libpthread.so.0 =><br>
/lib/x86_64-linux-gnu/<u></u>libpthread.so.0 (0x00007f6356757000)<br>
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.<u></u>1<br>
(0x00007f635653e000)<br>
libgcc_s.so.1 =><br>
/lib/x86_64-linux-gnu/libgcc_<u></u>s.so.1 (0x00007f6356327000)<br>
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.<u></u>6<br>
(0x00007f6355f61000)<br>
/lib64/ld-linux-x86-64.so.2 (0x00007f635d584000)<br>
libutil.so.1 =><br>
/lib/x86_64-linux-gnu/libutil.<u></u>so.1 (0x00007f6355d5d000)<br>
tfiala@tfiala2:/mnt/ssd/work/<u></u>macosx.sync/mbp-svn/build-<u></u>debug/lib$site-packages<br>
<br>
|<br>
<br>
The left side shows the short name that the .so is<br>
referencing. The right side shows what the loader<br>
actually mapped it to with the current environment. If<br>
there is a problem loading liblldb.so, this will show<br>
as (I think) question marks on the right side<br>
indicating that the shared library linkage was not<br>
found. Let me know if you see something like that.<br>
<br>
If you get past this part and you don’t see any<br>
issues, the next thing to try is:<br>
PYTHONPATH=/path/to/your/lldb/<u></u>lib/python2.7/site-packages<br>
python<br>
Then do an ‘import lldb’, then a ‘dir (lldb)’, like so:<br>
<br>
|tfiala@tfiala2:/mnt/ssd/work/<u></u>macosx.sync/mbp-svn/build-<u></u>debug/lib$<br>
PYTHONPATH=`pwd`/python2.7/<u></u>site-packages python<br>
Python 2.7.6 (default, Mar 22 2014, 22:59:56)<br>
[GCC 4.8.2] on linux2<br>
Type "help", "copyright", "credits" or "license" for<br>
more information.<br>
>>> import lldb<br>
>>> dir(lldb)<br>
['INT32_MAX', 'LLDB_ARCH_DEFAULT',<br>
'LLDB_ARCH_DEFAULT_32BIT', 'LLDB_ARCH_DEFAULT_64BIT',<br>
'LLDB_DEFAULT_BREAK_SIZE', 'LLDB_DEFAULT_SHELL',<br>
'LLDB_GENERIC_ERROR', 'LLDB_INVALID_ADDRESS',<br>
'LLDB_INVALID_BREAK_ID', 'LLDB_INVALID_CPUTYPE',<br>
'LLDB_INVALID_FRAME_ID', 'LLDB_INVALID_IMAGE_TOKEN',<br>
'LLDB_INVALID_INDEX32', 'LLDB_INVALID_IVAR_OFFSET',<br>
'LLDB_INVALID_LINE_NUMBER',<br>
'LLDB_INVALID_MODULE_VERSION', 'LLDB_INVALID_OFFSET',<br>
'LLDB_INVALID_PROCESS_ID', 'LLDB_INVALID_QUEUE_ID',<br>
'LLDB_INVALID_REGNUM', 'LLDB_INVALID_SIGNAL_NUMBER',<br>
'LLDB_INVALID_THREAD_ID', 'LLDB_INVALID_UID',<br>
'LLDB_INVALID_WATCH_ID', 'LLDB_MAX_NUM_OPTION_SETS',<br>
'LLDB_OPT_SET_1',<br>
<br>
... (lots of stuff removed)<br>
|<br>
<br>
That will tell you if you can load the lldb module<br>
when you specify exactly where it should be. If you<br>
can do this, the tests basically should not have<br>
trouble loading lldb. (Obviously somewhere we’ll find<br>
an issue here). If this does work, then we need to<br>
trace why the python test runner calls are mixing up<br>
the python path. In general you don’t need to specify<br>
any options to the ninja/make commands to get the<br>
tests to run from the build dir.<br>
<br>
Can you refresh my memory on what Linux distro you’re<br>
using and whether it’s 64 or 32 bit? (I don’t get over<br>
to the 32-bit distros much these days).<br>
<br>
I hope that gets us closer to finding out what’s up!<br>
Keep me posted.<br>
<br>
-Todd<br>
<br>
<br>
<br>
<br>
On Fri, Jul 18, 2014 at 4:56 AM, Matthew Gardiner<br>
<<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a> <mailto:<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>><br></div></div><div><div class="h5">
<mailto:<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a> <mailto:<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>>>> wrote:<br>
<br>
Hi Todd,<br>
<br>
Well I managed to get cmake and ninja working! I<br>
needed (it would<br>
appear) to download/build/install the latest<br>
versions of both from<br>
source. Then I do:<br>
<br>
build $ cmake ../llvm/ -G Ninja<br>
-DLLVM_TARGETS_TO_BUILD="X86"<br>
-DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_CXX1Y=ON<br>
...<br>
build $ ninja<br>
...<br>
<br>
However "ninja check-lldb" still fails to find<br>
lldb.py. It is does<br>
get built, but the path which dotest.py uses to<br>
find it is wrong<br>
on my system. Anyway, I'm going to continue trying<br>
to analyse it<br>
myself for now. I'll probably post a new thread to<br>
lldb-dev if I<br>
continue to struggle.<br>
<br>
Anyway, have a good weekend,<br>
Matt<br>
<br>
<br>
<br>
<br>
Member of the CSR plc group of companies. CSR plc<br>
registered in<br>
England and Wales, registered number 4187346,<br>
registered office<br>
Churchill House, Cambridge Business Park, Cowley<br>
Road, Cambridge,<br>
CB4 0WZ, United Kingdom<br>
More information can be found at <a href="http://www.csr.com" target="_blank">www.csr.com</a><br></div></div>
<<a href="http://www.csr.com" target="_blank">http://www.csr.com</a>> <<a href="http://www.csr.com" target="_blank">http://www.csr.com</a>>.<div class=""><br>
Keep up to date with CSR on our technical blog,<br>
<a href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a> <<a href="http://www.csr.com/blog" target="_blank">http://www.csr.com/blog</a>><br>
<<a href="http://www.csr.com/blog" target="_blank">http://www.csr.com/blog</a>>, CSR people blog,<br>
<a href="http://www.csr.com/people" target="_blank">www.csr.com/people</a> <<a href="http://www.csr.com/people" target="_blank">http://www.csr.com/people</a>><br>
<<a href="http://www.csr.com/people" target="_blank">http://www.csr.com/people</a>>, YouTube,<br>
<a href="http://www.youtube.com/user/CSRplc" target="_blank">www.youtube.com/user/CSRplc</a><br>
<<a href="http://www.youtube.com/user/CSRplc" target="_blank">http://www.youtube.com/user/<u></u>CSRplc</a>><br>
<<a href="http://www.youtube.com/user/CSRplc" target="_blank">http://www.youtube.com/user/<u></u>CSRplc</a>>, Facebook,<br>
<a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">www.facebook.com/pages/CSR/<u></u>191038434253534</a><br>
<<a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">http://www.facebook.com/<u></u>pages/CSR/191038434253534</a>><br>
<<a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">http://www.facebook.com/<u></u>pages/CSR/191038434253534</a>>,<br>
or follow us<br>
on Twitter at <a href="http://www.twitter.com/CSR_plc" target="_blank">www.twitter.com/CSR_plc</a><br>
<<a href="http://www.twitter.com/CSR_plc" target="_blank">http://www.twitter.com/CSR_<u></u>plc</a>><br>
<<a href="http://www.twitter.com/CSR_plc" target="_blank">http://www.twitter.com/CSR_<u></u>plc</a>>.<br>
New for 2014, you can now access the wide range of<br>
products<br>
powered by aptX at <a href="http://www.aptx.com" target="_blank">www.aptx.com</a><br></div>
<<a href="http://www.aptx.com" target="_blank">http://www.aptx.com</a>> <<a href="http://www.aptx.com" target="_blank">http://www.aptx.com</a>>.<div class=""><br>
<br>
<br>
<br>
<br>
-- Todd Fiala | Software Engineer |<br>
<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> <mailto:<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>><br></div>
<mailto:<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> <mailto:<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>>><br>
| <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a> <tel:<a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a>><div class=""><br>
<br>
<br>
<br>
<br>
To report this email as spam click here<br>
<<a href="https://www.mailcontrol.com/sr/ik8jrXaVfBTGX2PQPOmvUj%21GOBh06pKK3+K9eZ%212Dx6F%21Jeeftdx9RBpik88jjuoRisi26jPZSzJaydNu2tBwg==" target="_blank">https://www.mailcontrol.com/<u></u>sr/ik8jrXaVfBTGX2PQPOmvUj%<u></u>21GOBh06pKK3+K9eZ%212Dx6F%<u></u>21Jeeftdx9RBpik88jjuoRisi26jPZ<u></u>SzJaydNu2tBwg==</a>>.<br>
<br>
<br>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br></div>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a> <mailto:<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>><div class=""><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
<br>
<br>
<br>
<br>
<br>
-- Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a><br></div>
<mailto:<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> | <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a><br>
<br>
<br>
<br>
<br><span class=""><font color="#888888">
<br>
-- <br>
Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> <mailto:<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> | <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a><br>
<br>
<br>
</font></span></blockquote>
<br>
</blockquote></div><br></div></div></div>