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

python2 breaking lldb on osx #2730

Closed
chsitter opened this Issue Jul 5, 2016 · 10 comments

Comments

5 participants
@chsitter

chsitter commented Jul 5, 2016

Bug reports:

I've installed vim brew install vim --replace-system-vi on my mac and it has a dependency on python2. This dependency seems to be pulling down a 32bit readline.so and possibly other libraries that conflict with system libraries and break other tools. In my case it's lldb

chsitter: build$ lldb ./container.test
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py", line 98, in <module>
    import six
ImportError: No module named six
(lldb) target create "./container.test"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
.... (this repeats for some time)

I'm not sure whether this is the right place to raise this, but it seemed fitting.

@rakkesh

This comment has been minimized.

Show comment
Hide comment
@rakkesh

rakkesh Jul 5, 2016

Contributor

Doesn't seem like an issue with Homebrew.

Overriding system vi, Homebrew only symlinks vim to /usr/local/bin/vi
bin.install_symlink "vim" => "vi" if build.with? "override-system-vi"

readline formula is key-only and should not interfere with system libs.

Contributor

rakkesh commented Jul 5, 2016

Doesn't seem like an issue with Homebrew.

Overriding system vi, Homebrew only symlinks vim to /usr/local/bin/vi
bin.install_symlink "vim" => "vi" if build.with? "override-system-vi"

readline formula is key-only and should not interfere with system libs.

@MikeMcQuaid

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Jul 5, 2016

Member

It's an issue with the system LLDB and any python in the PATH, I suspect. Also agree this isn't a Homebrew issue (or at least: it's not something we can fix).

Member

MikeMcQuaid commented Jul 5, 2016

It's an issue with the system LLDB and any python in the PATH, I suspect. Also agree this isn't a Homebrew issue (or at least: it's not something we can fix).

@chsitter

This comment has been minimized.

Show comment
Hide comment
@chsitter

chsitter Jul 5, 2016

I'm not familiar enough with homebrew to investigate how and what but I believe it's an issue in the python formula. No package that is installed via a package manager should break a fundamental utility like lldb.

Someone suggested it might be down to the readline.so being for the wrong architecture which (I'd assume) can be fixed in the formula?

Haven't yet looked into it at all tbh - fixed it by using python3 and not having homebrew install python2 - but I can certainly do that if it helps

chsitter commented Jul 5, 2016

I'm not familiar enough with homebrew to investigate how and what but I believe it's an issue in the python formula. No package that is installed via a package manager should break a fundamental utility like lldb.

Someone suggested it might be down to the readline.so being for the wrong architecture which (I'd assume) can be fixed in the formula?

Haven't yet looked into it at all tbh - fixed it by using python3 and not having homebrew install python2 - but I can certainly do that if it helps

@MikeMcQuaid

This comment has been minimized.

Show comment
Hide comment
@MikeMcQuaid

MikeMcQuaid Jul 5, 2016

Member

No package that is installed via a package manager should break a fundamental utility like lldb.

On the flip side: nothing installed into /usr/local should break a system utility.

Member

MikeMcQuaid commented Jul 5, 2016

No package that is installed via a package manager should break a fundamental utility like lldb.

On the flip side: nothing installed into /usr/local should break a system utility.

@mistydemeo

This comment has been minimized.

Show comment
Hide comment
@mistydemeo

mistydemeo Jul 7, 2016

Contributor

The problem is caused by the six module not being available. Like Mike said, it looks like the system lldb uses whichever python is first on the PATH. The Python script lldb uses requires the six module, which is preinstalled with the OS python but not with Homebrew's python. If you pip install six then lldb will work fine.

Contributor

mistydemeo commented Jul 7, 2016

The problem is caused by the six module not being available. Like Mike said, it looks like the system lldb uses whichever python is first on the PATH. The Python script lldb uses requires the six module, which is preinstalled with the OS python but not with Homebrew's python. If you pip install six then lldb will work fine.

@tdsmith

This comment has been minimized.

Show comment
Hide comment
@tdsmith

tdsmith Jul 10, 2016

Contributor

^ Actually there's a good chance it'll crash because _lldb.so is linked against the system Python!

It's odd to me that we haven't seen this before.

Contributor

tdsmith commented Jul 10, 2016

^ Actually there's a good chance it'll crash because _lldb.so is linked against the system Python!

It's odd to me that we haven't seen this before.

@tdsmith

This comment has been minimized.

Show comment
Hide comment
@tdsmith

tdsmith Jul 10, 2016

Contributor

I can reproduce with Homebrew's python linked by running pip uninstall six and launching lldb, though, so I guess it doesn't crash after all.

I propose that this is Apple's bug.

Contributor

tdsmith commented Jul 10, 2016

I can reproduce with Homebrew's python linked by running pip uninstall six and launching lldb, though, so I guess it doesn't crash after all.

I propose that this is Apple's bug.

@chsitter

This comment has been minimized.

Show comment
Hide comment
@chsitter

chsitter Jul 10, 2016

Sounds to me like installing the six module with the python package by default (to avoid screwing up lldb) and raising an issue with Apple would be the right thing to do?

Sounds to me like installing the six module with the python package by default (to avoid screwing up lldb) and raising an issue with Apple would be the right thing to do?

@tdsmith

This comment has been minimized.

Show comment
Hide comment
@tdsmith

tdsmith Jul 10, 2016

Contributor

I'd feel worse about it if anyone had ever complained before, tbh. six is fine and bundling it with python would be fine but I don't really want to start curating a shadow stdlib. I propose to close this without action and ask you to file an issue with Apple asking them to modify lldb to use system Python.

Contributor

tdsmith commented Jul 10, 2016

I'd feel worse about it if anyone had ever complained before, tbh. six is fine and bundling it with python would be fine but I don't really want to start curating a shadow stdlib. I propose to close this without action and ask you to file an issue with Apple asking them to modify lldb to use system Python.

@chsitter

This comment has been minimized.

Show comment
Hide comment
@chsitter

chsitter Jul 10, 2016

Sounds sensible. Guessing nobody uses languages that require lldb to debug any more :)

There are easy ways to fix this, hence it's not really a big issue and I've got it working now, so happy to close it.

Thanks for looking into it

Sounds sensible. Guessing nobody uses languages that require lldb to debug any more :)

There are easy ways to fix this, hence it's not really a big issue and I've got it working now, so happy to close it.

Thanks for looking into it

@chsitter chsitter closed this Jul 10, 2016

@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.