Error when importing sqlite3 in Python. Broken SQLite.

[magandrez]

• Ran brew update and retried your prior step?
  No new updates for sqlite or python packages.
• Ran brew doctor, fixed as many issues as possible and retried your prior step?
  Not applicable.
• If you're seeing permission errors tried running sudo chown -R $(whoami) $(brew --prefix)?
  Not applicable.

Bug reports:

Python (2.7.11) throws error when importing sqlite3:

spav:workbench spav$ python -c "import sqlite3"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sqlite3/__init__.py", line 24, in <module>
    from dbapi2 import *
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sqlite3/dbapi2.py", line 28, in <module>
    from _sqlite3 import *
ImportError: No module named _sqlite3

This is similar error to the one described in the old issue #17312 Instructions in that issue point to brew rm sqlite python && brew install python However this fix does not work.

Moreover, checking the debug logs for python package I found the following:

baldur:python spav$ less 02.make | grep "_sqlite3" 
*** WARNING: renaming "_sqlite3" since importing it failed: dlopen(build/lib.macosx-10.11-x86_64-2./_sqlite3.so, 2): Symbol not found: _sqlite3_enable_load_extension
Referenced from: build/lib.macosx-10.11-x86_64-2.7/_sqlite3.so 
in build/lib.macosx-10.11-x86_64-2.7/_sqlite3.so_sqlite3

Any idea what is happening?

-Manuel

[tdsmith]

Can you share brew gist-logs python?

[magandrez]

Sure, here is the whole trace:

https://gist.github.com/27e53de5119dd0f0404e

[tdsmith]

What's nm -gj /usr/local/opt/sqlite/lib/libsqlite3.dylib | grep enable_load_extension give you? I don't see any smoking guns.

[magandrez]

@tdsmith This is the output:

_sqlite3_enable_load_extension

[tdsmith]

Sorry for the delay. Can you try:

1. Run brew edit python and add a line reading interactive_shell after system "make"
2. Once you get a prompt, run find . -name \*sqlite3\*so\* -exec otool -L {} \; and paste the output here

Alternatively, you can install the Xcode Command-Line Tools with xcode-select --install and you'll get a bottle which won't have this problem.

[magandrez]

Hi again,

This is the output:

bash-3.2$ find . -name \*sqlite3\*so\* -exec otool -L {} \;
./build/lib.macosx-10.11-x86_64-2.7/_sqlite3_failed.so:
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 216.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

[tdsmith]

Okay, that's interesting; the failed module is being linked against the system libsqlite.

The failing clang invocation is:

superenv executed: clang -pipe -w -Os -march=native -bundle -undefined dynamic_lookup build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/cache.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/connection.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/cursor.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/microprotocols.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/module.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/prepare_protocol.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/row.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/statement.o build/temp.macosx-10.11-x86_64-2.7/private/tmp/python20160301-55377-1bj68zx/Python-2.7.11/Modules/_sqlite/util.o -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib -lsqlite3 -o build/lib.macosx-10.11-x86_64-2.7/_sqlite3.so -Wl,-search_paths_first -isysroot /Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk --sysroot=/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -isystem/usr/local/include -isystem/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/libxml2 -isystem/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/apache2 -isystem/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/openssl/lib -L/usr/local/lib -L/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -Wl,-headerpad_max_install_names

[tdsmith]

I don't get the double slashes here. I think superenv is failing to do the right thing because the double slashes are confusing it. What does xcode-select -p print? I think sudo xcode-select -s /Applications/Xcode.app/Contents/Developer will fix this.

[magandrez]

Hi @tdsmith

It does actually print /Applications/Xcode.app/Contents/Developer/ with the trailing slash. And indeed establishing the same path without the trailing slash solves the problem. Great work!