Red Hat Bugzilla – Bug 189748
_sqlite.so cannot resolve a symbol when dbapi2.py imported.
Last modified: 2007-11-30 17:11:31 EST
Description of problem: python-sqlite2 does not appear to be built against the same version of sqlite3 that is shipped with Fedora Core. There is a missing symbol somewhere (see traceback below). Version-Release number of selected component (if applicable): python-sqlite2: 2.2.2-1.fc5 sqlite: 3.3.3-1.2 How reproducible: Always Steps to Reproduce: 1. Start python 2. Try to use pysqlite2 in a non-trivial fashion. For example: >>> from pysqlite2 import dbapi2 Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib64/python2.4/site-packages/pysqlite2/dbapi2.py", line 27, in ? from pysqlite2._sqlite import * ImportError: /usr/lib64/python2.4/site-packages/pysqlite2/_sqlite.so: undefined symbol: sqlite3_enable_shared_cache
Thank you for your bug report. I have few questions: - Is it really ia64 arch or x86_64? Currently Fedora Extras only supports i386, x86_64 and ppc platforms. - Can you paste here output of these commands? nm -D /usr/lib64/libsqlite3.so | grep sqlite3_enable_shared_cache rpm -q --qf '%{name}-%{version}-%{release}.%{arch} %{vendor}\n' sqlite python-sqlite2
Apologies about the architecture. You are correct; brain failure on my part somewhere. I'm using x86_64. As for the other information, that finally triggered me into thinking about what was happening. Including the resolution here in case somebody else stumbles across this bug. .-(malcolm@counterweight 10:23:21) ~ `--> nm -D /usr/lib64/libsqlite3.so | grep sqlite3_enable_shared_cache 0000003c57126190 T sqlite3_enable_shared_cache Hmm... bizarre. So why am I getting the error (I think to myself). Eventually, I realise --> ldd /usr/lib64/python2.4/site-packages/pysqlite2/_sqlite.so libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x00002aaaaabda000) ... D'oh! I'm a bozo. Removing the locally installed version from before I upgraded to FC5 fixes everything. I really didn't think this through before reporting it. :-( Closing as NOTABUG (since REPORTER_IS_STUPID is not an option).
I have traced an issue with yum on my system where it claimed a module called sqlite did not exist. Eventually after much stracing and discovering python -m yum I was able to trace it down to a python module called dbapi2 missing a symbol called sqlite3_enable_shared_cached. Looking at the output from ldconfig -p I noted that there were two versions of libsqlite3.so.0 x86_64 on the system. Ammending LD_LIBRARY_PATH to /usr/lib64 and re-running yum cleared this issue. The cause of yum not working was not obvious, and the eventual resolution far from what I had expected. Having a second copy of the file libsqlite3.so.0 in /usr/local was the cause of the issue in my case, but I would imagine I'm not the only person that will get tripped up by this one. Perhaps if I had understood the search sequence of ld.so.conf.d better, I would have picked upon my ushare entry for /usr/local/lib which takes in sqlite. My eight cents. No actions required, just commenting.