Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?
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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?
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. 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) * 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 * Dynamically load any supported Python DLL if/when needed On Thu, Nov 21, 2019 at 1:57 PM Leonard Mosescu wrote: > What kind of behavior did you expect? > > I could be wrong, but I thought that previous versions of LLDB would use > LoadLibrary() instead of linking to the import library? > > -- > *From:* Pavel Labath > *Sent:* Wednesday, November 20, 2019 11:32 PM > *To:* Adrian McCarthy ; Leonard Mosescu < > lmose...@nvidia.com> > *Cc:* lldb-dev@lists.llvm.org > *Subject:* Re: [lldb-dev] The pre-built Windows LLDB binary has a > dependency on an external python36.dll? > > On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote: > > That said, I didn't expect an explicit dependency on python36.dll. > > What kind of behavior did you expect? > > pl > -- > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all copies > of the original message. > -- > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Website is not being updated
I see a bunch of eros here: http://lists.llvm.org/pipermail/www-scripts/2019-November/thread.html Is this possibly related to the Github/monorepo transition? -- Jonas On Thu, Nov 21, 2019 at 10:52 AM Adrian Prantl via lldb-dev wrote: > > Hello Tanya, > > it looks like the cron job that is supposed to be updating the LLDB website > isn't running or is otherwise blocked at the moment. You can see on > https://lldb.llvm.org that it says "Welcome to the LLDB version 8 > documentation!". We also recently removed the "Why a New Debugger?" headline > and that change isn't showing up either. > > Would you mind taking a look? > > thanks for your help, > Adrian > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?
What kind of behavior did you expect? I could be wrong, but I thought that previous versions of LLDB would use LoadLibrary() instead of linking to the import library? From: Pavel Labath Sent: Wednesday, November 20, 2019 11:32 PM To: Adrian McCarthy ; Leonard Mosescu Cc: lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll? On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote: > That said, I didn't expect an explicit dependency on python36.dll. What kind of behavior did you expect? pl --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB Website is not being updated
Hello Tanya, it looks like the cron job that is supposed to be updating the LLDB website isn't running or is otherwise blocked at the moment. You can see on https://lldb.llvm.org that it says "Welcome to the LLDB version 8 documentation!". We also recently removed the "Why a New Debugger?" headline and that change isn't showing up either. Would you mind taking a look? thanks for your help, Adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Openmp-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
> In addition to being used for post-commit testing, having these CI definitions in the > main tree will make it easier for me (or anyone) to do pre-commit testing for the > release branch in a personal fork. I find this part especially useful. I'm using these actions on a personal branch to validate patches on Linux, OSX and Windows, which gives me more confidence on its portability. On Thu, Nov 21, 2019 at 10:15 AM Christian Kühnel via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi Tom, > > First of: I'm a big fan of adding more automatic tests to find bugs. Great > work! > > On the other hand, I think we should consider creating some sort of test > strategy for the LLVM project: > >- What tests do we expect users to run before uploading patches? >- What tests do we expect users to run before merging? >- What tests do we run after merging? >- What failures must be fixed, what failures can be ignored? >- What do we check for on the build bots? >- What do we check for on the release branches? >- What do we check for on the pre-merge tests? >- Which CI tools do we want to use (github, Jenkins, bulidbot, ...)? >- What about running clang-tidy and clang-format? >- What CMake configurations should we check? (Release/Debug, >assertions, ...) >- Do we want to run tests with Sanitizers? >- Which of these systems do we expect users to monitor? > > I suppose it would be good to have a document that summarizes all of this > so that we > >1. do not test the same thing twice and >2. do not miss any important checks. > > Does something like this exist? > Is anyone working on this? > > Best, > Christian > > On Wed, Nov 20, 2019 at 7:26 AM Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> > Hi Tom, >> > >> > This sounds very interesting! +1 from me. >> > What does this imply for the release testers? >> > Would it be possible / desirable for us to add self-hosted runners for >> > other architectures? I'm assuming GitHub only provides x86, right? I >> > totally missed any details about that in their docs, but it seems to >> > be implied here [1]. I'm not saying we should go all-possible-arches >> > from the start, we can definitely try it out only for x86 this time >> > around if you think that would be the best approach. >> > >> >> Nothing changes for release testers at this point. The main goal here is >> to get some post-commit testing so we can catch issues in the branch >> early. >> >> Longer term I think have self-hosted runners would be great, because it >> would >> allow us to fully automate the testing and uploading we do when a release >> gets >> tagged. >> >> You are correct that GitHub only provides x86 machines, however, they >> don't >> have enough disk space (14GB) to be able to run the test-release.sh >> script, so >> adding x86 self-hosted builders with more disk space would still be very >> useful. >> >> -Tom >> >> > >> > [1] >> https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ >> > >> > Thanks, >> > Diana >> >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > Best, > Christian > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
