[SR-14] Wrong python version selected when building swift-lldb

[octoploid]

Previous ID	SR-14
Radar	None
Original Reporter	@octoploid
Type	Bug
Status	Resolved
Resolution	Cannot Reproduce

Attachment: Download

Additional Detail from JIRA

Votes	3
Component/s	LLDB for Swift
Labels	Bug
Assignee	None
Priority	Medium

md5: d379de56b4707da9e6dfce4bc46064ff

Issue Description:

On my system both python-3.4 and python-2.7 are installed.
swift-lldb selects the wrong version (3.4):

...
[6/840] Building CXX object scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o
FAILED: /usr/local/bin/clang++   -DHAVE_PROCESS_VM_READV -DHAVE_ROUND -DLIBXML2_DEFINED -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Dreadline_EXPOR
TS -Iscripts/Python/modules/readline -I/var/tmp/lldb/scripts/Python/modules/readline -I/var/tmp/lldb/include -Iinclude -I/var/tmp/build/Ninja-ReleaseAssert/llvm-linux-x86_64/
include -I/var/tmp/build/Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/include -I/var/tmp/llvm/include -I/var/tmp/llvm/tools/clang/include -I/var/tmp/build/Ninja-ReleaseA
ssert/swift-linux-x86_64/include -I/var/tmp/swift/include -I/var/tmp/lldb/source -I/usr/include/python3.4 -I/var/tmp/lldb/tools/clang/include -I../clang/include -I/usr/includ
e/libxml2 -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-dep
recated-register -Wno-vla-extension  -fno-exceptions -fno-rtti -Wno-macro-redefined -O3 -DNDEBUG -fPIC -MMD -MT scripts/Python/modules/readline/CMakeFiles/readline.dir/readli
ne.cpp.o -MF scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o.d -o scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o -c /var/tmp/ll
db/scripts/Python/modules/readline/readline.cpp
/var/tmp/lldb/scripts/Python/modules/readline/readline.cpp:68:34: error: assigning to 'char *(*)(FILE *, FILE *, const char *)' (aka 'char *(*)(_IO_FILE *, _IO_FILE *, const 
char *)') from incompatible type 'char *(FILE *, FILE *, char *)' (aka 'char *(_IO_FILE *, _IO_FILE *, char *)'): type mismatch at 3rd parameter ('const char *' vs 'char *')
    PyOS_ReadlineFunctionPointer = simple_readline;
                                 ^ ~~~~~~~~~~~~~~~
/var/tmp/lldb/scripts/Python/modules/readline/readline.cpp:70:5: error: use of undeclared identifier 'Py_InitModule4'
    Py_InitModule4(
    ^
2 errors generated.

[trfiala]

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!

[octoploid]

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...

[trfiala]

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.

[trfiala]

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.

[swift-ci]

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.

[swift-ci]

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.

[swift-ci]

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?

[swift-ci]

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.

[Dante-Broggi]

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

[adrian-prantl]

Please reopen if this is still an issue.