Conversation
The Python used to run lit can be different from the Python LLDB was build with. One scenario where this happens is when LLVM can find the Python 3 interpreter, but not the Python 3 libraries, in which case LLDB build and links against Python 3. Without this change, you end up with an ModuleNotFoundError because of the mismatch. Instead of looking at the Python interpreter that's used to run lit, lldbtest should use the interpreter that matches the Python version LLDB was build against. Differential revision: https://reviews.llvm.org/D79519 (cherry picked from commit 7c6420e)
The Python 3 interpreter in Xcode has a relative RPATH and dyld fails to load it when we copy it into the build directory. This patch adds an additional check that the copied binary can be executed. If it doesn't, we assume we're dealing with the Xcode python interpreter and return the path to the real executable. That is sufficient for the sanitizers because only system binaries need to be copied to work around SIP. This patch also moves all that logic out of LLDBTest and into the lit configuration so that it's executed only once per test run, instead of once for every test. Although I didn't benchmark the difference this should result in a mild speedup. Differential revision: https://reviews.llvm.org/D81696 (cherry picked from commit 526e0c8)
|
Should fix issues like https://ci.swift.org/job/oss-swift-package-ubuntu-20_04/362/console |
|
@swift-ci please test |
|
Im fine with these being cherry-picked, but the question is should it be on stable/20200108 instead (as @adrian-prantl kindly reminded me). Seems that both already made the cutoff for stable/20200714, so that branch should be fine. |
|
No, these changes should go to master. Adrian's statement is correct: all cherrypick form llvm.org should go to the The changes in this PR should not go to swift 5.3 so that's why I'm cherry-picking them to PS: I already cleared this up with @adrian-prantl offline. |
No description provided.