_io.so flat namespace

[bugbee]

BPO	26498
Nosy	@ned-deily

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-03-08.08:30:30.937>
created_at = <Date 2016-03-07.05:30:41.321>
labels = ['invalid', 'library', 'expert-IO', 'type-crash']
title = '_io.so flat namespace'
updated_at = <Date 2016-03-08.08:30:30.935>
user = 'https://bugs.python.org/bugbee'

bugs.python.org fields:

activity = <Date 2016-03-08.08:30:30.935>
actor = 'bugbee'
assignee = 'none'
closed = True
closed_date = <Date 2016-03-08.08:30:30.937>
closer = 'bugbee'
components = ['Library (Lib)', 'IO']
creation = <Date 2016-03-07.05:30:41.321>
creator = 'bugbee'
dependencies = []
files = []
hgrepos = []
issue_num = 26498
keywords = []
message_count = 4.0
messages = ['261278', '261305', '261306', '261333']
nosy_count = 2.0
nosy_names = ['bugbee', 'ned.deily']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue26498'
versions = ['Python 2.7']

[bugbee]

On OSX El Capitan, Python v2.7.10 and 2.7.11 (standard installer)...

When importing urllib2 it crashes with a flat namespace error then loading _io.so. Shortest test case: "python -c 'import urllib2'"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 94, in <module>
    import httplib
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
    import mimetools
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
    import tempfile
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

This error occurs under both v2.7.10 and v2.7.11. When I regress to 2.7.9 and all is well.

[ned-deily]

Sorry, I am unable to reproduce the problem. My guess is that somehow there is a version mismatch between the Python executable and the dynamic libraries. This *could* be caused by a number of things, like environment variable settings. Suggest trying to isolate the problem by checking the following in a bash shell:

$ type python
python is hashed (/usr/local/bin/python)
$ which python
/usr/local/bin/python
$ ls -l $(which python)
lrwxr-xr-x  1 root  wheel  68 Jan  2 23:08 /usr/local/bin/python -> ../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python
$ python -c 'import sys;print(sys.version)'
2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 12:54:16)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
$ /usr/local/bin/python2.7 -c 'import urllib2'
$ env | sort
# look for LD_* and DYLD_* variables
$ python -v -c 'import urllib2'

[ned-deily]

An even more likely scenario: the Python executable you are using is coming from an older virtualenv. If so, you need to update the virtualenv to include an up-to-date python executable.

[bugbee]

Ned, thank you for your suggestions.

Just so you know, my HD recently crashed so I rebuilt the system with a new SSD. I was previously running 2.7.9 so I installed 2.7.9 to minimize any potential conflicts with my code base. All was well.

Now it was time to rev Python to 2.7.11 and that was when the problem occurred. ...so I tried 2.7.10 and then 2.7.9. I hadn't gotten around to virtualenv so all these Python installs were on top of each other in /Library/Frameworks/...

Following your suggestion, with 2.7.9 installed, I ran your commands and the output was as expected. I did notice, however, a lot of [benign?] cruft in my .profile and .bashrc and thought it best to clean them up. Ok, still good. I then installed 2.7.11 and reran your commands. Again, everything worked as expected. Huh?

I restored back to my earlier versions of .profile and .bashrc (cruft included), and am still unable to reproduce. :-/ I've tested and retested. All is still well, so sadly I'm unable to report the cause. I suggest we close the report.

Changing the subject slightly... I noticed that each time we do an install of Python, another path is prepended to PATH even if there is already an identical entry in .profile. Did I mention cruft? ;-) Hard perhaps, but is there a way for the install script to mock execute .profile to devine the resulting PATH, inspecting it for the desired path rather than just blindly adding it to .profile? ...just a thot.

Again, thanks for your help. I'm off and running.