lldb-3.8.1 prebuilt binary for windows7

Does the 4.0 binary not work for you? It is the first release that contains prebuilt lldb binary.

Looks like the Python API is not included though. Do you know why it was left out?

I imagine that Hans doesn’t have Python 3 installed on his system, so LLDB didn’t autoconfigure with Python support.

He said he did, so I don’t know. Vadim, can you elaborate? When you run lldb -P from the command line, what do you see?

It outputs ‘c:\Program Files (x86)\LLVM\lib\site-packages’, however the ‘site-packages’ directory does not exist. Nor do I see ‘_lldb.pyd’ anywhere else.
‘script import lldb’ also fails, of course.

I may know what this is. Can you try setting PYTHONPATH though to point to your Python 3.5 installation though and see if it fixes it? (I don’t think it will, but let’s try anyway)

Nope, that didn’t help.

I think it is a problem with the way we built lldb. I will look into what additional steps we need to take when making the prebuilt binary so that it works next time.

This is still broken in the October snapshot. Do you know which script is used to build the Windows installer?

I believe the way to fix this is going to be building LLDB for the installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time

+Ted, since I believe he is one of the few people currently using this flag.

Windows has no concept of a default python installation, and I can’t be sure what version of python my users have, if any, so I need to solve 2 problems:

  1. Where is python when I’m building?

  2. Where is python when I’m running?

To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my python installation (on our buildbots, c:/python351).

#2 only needs to be solved if the machine you’re running on doesn’t have the same python installation, in PYTHON_HOME above. To do that, I’ve added code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro down to InitializePythonHome in source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and call Py_SetPythonHome with it. My installations have the python dll and python library directory. We put the library in /lib/python35 and the dll in /bin.

So it sounds like you’re saying that in order for Python support to work as part of an LLDB shipped in the installer, we need to do set 3 variables at CMake time.

  1. -DLLDB_RELOCATABLE_PYTHON=TRUE
  2. -DPYTHON_HOME =
  3. -DLLDB_DEFAULT_PYTHON_HOME=TRUE

Now because of #3, the lldb shipped in the installer will use the PYTHONHOME system environment variable to locate python, which must point to a valid Python 3.5 installation. Is this correct?

The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and -DPYTHON_HOME=<path>.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

Please correct me if I’m wrong, but isn’t the issue here that LLDB’s Python support files don’t get packaged into the Windows installer? Does packaging them somehow depend on knowing what the Python installation path is?

I overlooked that part of it, but yes that is another separate issue. (BTW, _lldb.pyd is simply a symlink to liblldb.dll).

In any case, yea I think the entire lib/site-packages folder needs to be included.

At least on my machine, finding Python is not the problem, because Python installer has added C:\Python35 to the PATH. (It can also be found in the Registry at
HKLM\SOFTWARE\Python\PythonCore\3.5-32\InstallPath).

BTW, _lldb.pyd is just a symlink of liblldb.dll. Perhaps you could try creating the symlink manually and copying the other files (e.g. embedded_interpreter.py, six.py, etc) over to see if it works. If it does, it would at least confirm that this is everything we need to do to get it working for you, so that we can have some confidence the next release doesn’t have the problems.

LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a while, it conflicted with Zach’s implementation, but I redid it, and everything is happy now. If you think it would be useful, I could upstream it. It’s fairly small, and plays nice with Zach’s Python stuff.

The problem it solves is “where is my python?” on Windows. If you know you’ll be running on a system with the same python installation as the build system, then you don’t need it. Or if you can tell your users to install the same python you built with, in the same location, you’re OK. I can’t do that, so instead I ship python, and tell lldb where to find it at build time.

We copy over the full site-packages directory that is created by the lldb build, and end up with this directory structure:

bin/lldb.exe

bin/liblldb.dll

bin/python35.dll

lib/python35

lib/site-packages

Is there a tarball somewhere that I can pull those files out from?

I tried with an older build I have on my machine; and copying site-packages over into %LLVM%\lib did allow lldb module loading to get a bit further, but it still failed because SWIG-generated wrapper does not match the .pyd module.

Is anyone working on this?

I'm happy to include LLDB in the installer, but I'm really not the
best person to be debugging it.

If more files need to be included in the install, that's configured in
the CMake files (what's installed by the 'install' build target is
also what ends up going into the installer). If it needs more build
flags, patches to build_llvm_package.bat are welsome.

Thanks,
Hans

Hi Hans,

I'd love to help, but I don't have half the tools that build_llvm_package.bat
requires installed on my machine. My setup is to build llvm with msbuild.
  Is it possible to build the installer this way too?

Can you point me to the specific CMake source that determines what's
included in the package? At a glance, everything from
%LLVM%/lib/site-packages is missing.

Vadim

Is anyone working on this?

I'm happy to include LLDB in the installer, but I'm really not the