Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
octoploid mannequin opened this issue Dec 3, 2015 · 10 comments
Closed

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

octoploid mannequin opened this issue Dec 3, 2015 · 10 comments
Labels
bug Something isn't working LLDB for Swift

Comments

@octoploid
Copy link
Mannequin

octoploid mannequin commented Dec 3, 2015

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
Copy link
Mannequin

trfiala mannequin commented Dec 4, 2015

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
Copy link
Mannequin Author

octoploid mannequin commented Dec 4, 2015

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
Copy link
Mannequin

trfiala mannequin commented Dec 4, 2015

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
Copy link
Mannequin

trfiala mannequin commented Dec 4, 2015

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
Copy link

swift-ci commented Dec 8, 2015

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
Copy link

swift-ci commented Dec 8, 2015

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
Copy link

swift-ci commented Jan 6, 2016

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
Copy link

swift-ci commented Mar 1, 2016

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
Copy link

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

@adrian-prantl
Copy link
Member

Please reopen if this is still an issue.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

3 participants