[SR-14] Wrong python version selected when building swift-lldb about llvm-project HOT 10 CLOSED

Hi Markus,

Thanks for filing the bug!

Can you tell me a bit more about your setup?

Which OS exactly, which packages are installed, and how you installed them? I'd like to make sure I have a valid repro environment.

I think this could be a bad interaction with some work being done in llvm.org lldb to support Python 3.x for Windows. The code for Linux in that override readline Python module (the site of your error) looks to be no longer valid for Python 3.x. (It might be unrelated, but I've built on Linux quite a bit in the past with both python 2 and 3 installed and hadn't hit this back then. I think this has crept in somewhat recently).

I'd be inclined to try to prevent a Python 3.x from being chosen on Linux for now.

Thanks in advance for digging up and passing along the repro environment!

from llvm-project.

Trying to prevent Python 3.x from being chosen on Linux looks like the right fix.

I'm running Gentoo. The default Python version is 2.7.10. Python 3.4.3 is also installed.
I don't think that the specifics of the distro matter much for this issue.

Just running ":%s/python3.4/python2.7/g" on /var/tmp/build/Ninja-ReleaseAssert/lldb-linux-x86_64/build.ninja in vim fixed the issue for me...

from llvm-project.

The bug linked upstream is the place where this issue should be fixed. After resolving there, it can be cherry picked into swift.org swift-lldb.

from llvm-project.

Okay, thanks Markus. I had thought this was on an Ubuntu system, but thanks for clarifying it was Gentoo. Haven't been there for a while, but that's a nice and clean system! (I used to do Gentoo on PowerPC Macs back in early 2000s in addition to the x86 machines).

I'm glad you have a work-around. Let's keep this open until we have it really resolved for others, though. The llvm.org bug will track the real work, but that's discoverable from here now.

from llvm-project.

Comment by James Laver (JIRA)

Some new anecdata:

• utils/build-script -R works on my machine

• utils/build-script --preset=buildbot_linux_1510 does not work with this same error.

I'm running gentoo. Python 2.7 is selected by eselect. Curiously, if I export EPYTHON=python2.7 before building it doesn't cause this error. Don't know quite what's going on there.

from llvm-project.

Comment by Elvis Stansvik (JIRA)

I'm hitting this on Arch. I attached my quick fix to the LLDB bug report. Hopefully this will get sorted soon.

from llvm-project.

Comment by Tom Gall (JIRA)

This all boils down to a couple of issues:

1) lldb/scripts/Python/modules/readline/readline.cpp : It's just not python 3 ready. I module initialization at a glance looks like it needs to be rewritten.

2) The cmake infrastructure in lldb isn't doing proper python detection anyway. Python 2.7 seems to be a hard dep based on the code right now, yet cmake and friends will happily choose 3.4 over 2.7.

Backing up, why isn't -DLLDB_DISABLE_PYTHON:BOOL=ON reasonable? Does swift/lldb really need python support?

from llvm-project.

Comment by Ryan Lovelett (JIRA)

I had been using the patch in the "upstream llvm.org lldb bug" link; however as of 45b60689698b8d66e0de5517d9cfe2396a6093c4 the patch no longer applies.

45b60689698b8d66e0de5517d9cfe2396a6093c4 is the first bad commit
commit 45b60689698b8d66e0de5517d9cfe2396a6093c4
Author: Todd Fiala <todd.fiala@gmail.com>
Date:   Sat Feb 20 17:26:07 2016 -0800

    Revert "undo the llvm.org lldb svn trunk merge"

    This change restores the merge from llvm.org from Friday, plus
    fixes up all the test issues that failed to run and were not
    caught by changes to the test infrastructure upstream.

    This change enhances the lldb inline test mechanism to only
    run debuginfo variants that make sense for the platform.
    Previously it always ran all of them.

    This change only addresses issues on OS X.  A follow-up commit
    will be made to address known-to-exist Linux issues.  I want
    to run this change by the OS X pull request testing on the
    Swift LLDB CI first, though.

    This reverts commit 0c0701210828a9280d4ded63b087efc9cc74003a.

I've attached an updated patch that does.

from llvm-project.

Is this resolved? If so, this should be closed.

from llvm-project.

Please reopen if this is still an issue.

from llvm-project.