Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

I first noticed this issue when running print(lldb.SBHostOS.GetLLDBPythonPath()) in the script interpreter. It worked as expected on Linux and with an LLDB that I built on my machine, but when I ran it in an LLDB that our buildbots built, I got the wrong value – /lib/site-packages/lib/site-packages.

I checked both versions using Process Explorer to see loaded dlls. The version I built on my Windows machine (Win 10, VS 2017, Python 3.5.1, works) shows liblldb.dll. The version built on the bot (Windows Server 2016, VS 2017, Python 3.5.1, but doesn’t work) shows _lldb.pyd and liblldb.dll.

In both cases we use cmake to build a VS solution. On my machine I built lldb in Visual Studio. On the bot we call msbuild to build the RELEASE configuration. The bot then does an install. I also did an install, and my installed version works correctly.

Does anybody have any idea why lldb built on the bot would load the dll twice, but lldb built on my machine would load it once?

Ted

Just guessing: Does either machine have more than one Python installation?

Windows Server is, by default, more locked down than the standard editions, which can affect the search path. Perhaps you’re not getting the Python you think you’re getting on one of the machines.

Are both machines 64-bit? Are you launching Python from a 32- or 64-bit process? Is it the same on both machines?

I believe there are more than 1 python install on the machines, but we set the PYTHON_HOME cmake variable to get it to use the Python we want. Both copies spit out 3.5.1 when I print sys.version (but both are using the same python35.dll).

Both machines are 64 bit; I’m launching lldb from both a cmd window and by double clicking its icon. Behavior is the same either way.

Looking into differences, I’m using swig 3.0.12 and the bot is using swig 3.0.2. I’m building with 3.0.2 on my machine right now, but it will take a while to finish!

I think this could very likely be the cause. We use a different
mechanism
(<https://github.com/llvm/llvm-project/blob/master/lldb/bindings/python.swig#L34>)
for importing the lldb module starting with swig-3.0.11. This could very
well be one of the side effects.

pl