[lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Pavel Labath via lldb-dev]

On 22/11/2019 01:26, Adrian McCarthy wrote:
> Yes, that sounds plausible, but I don't recall for sure.  I think 
> there's a build-time option to say you don't want Python at all, but I 
> can't remember if there was a load-as-needed option.

I'm pretty sure we have never had explicit support for anything like 
this. The only way I can see this happening is if this fell out 
"accidentally" out of our lazy python initialization and some windows 
dll behavior, but I don't think windows has anything like that. (At 
least on linux, I know that lazy binding can delay library mismatch 
errors until the first time you call some function, but they won't help 
you if the library is not there at all.)

I think the more likely scenario is that python was disabled in the 
previous "official" releases, and that some of the python changes 
enabled it.

> 
> In any event, the current situation is what it is.  What's feasible and 
> worth doing for the future?
> 
> * Hard dependency (as we have right now)
I'm fine with that. We could add a note on the website that one needs to 
have python installed for this to work. Or we could disable python for 
the official releases.

> * Dynamically load Python DLL on startup if it exists, or provide a 
> better error message with instructions
> * Dynamically load Python DLL on startup if it exists, otherwise disable 
> Python-dependent features
> * Dynamically load a specific version of the Python DLL if/when needed
All of these seem fine too, if anyone is willing to invest the time to 
make it work (it shouldn't be _that_ hard). Since python is pretty 
compartmentalized nowadays, it shouldn't relatively easy to disable 
python features at runtime instead of just exiting.

The main question I have here is should we dlopen python.dll, or some 
lldb wrapper of it (the entire "script interpreter" plugin).

I'd also like to note that this isn't the only external dependency of 
lldb. (Well, it might be on windows..) Lldb can use libcurses, libedit, 
libz, etc. Libedit is fairly likely to not be present on a random linux 
system. libcurses are almost certainly there, but it's not always a 
compatible version, etc.

> * Dynamically load any supported Python DLL if/when needed
That might be tricky since the different versions are not binary 
compatible in general. But it is possible, as Apple folks have shown, 
though it amounts to building multiple copies of ScriptInterpreterPython 
and then choosing the right one at runtime.

pl