Bug 189748 - _sqlite.so cannot resolve a symbol when dbapi2.py imported.
_sqlite.so cannot resolve a symbol when dbapi2.py imported.
Product: Fedora
Classification: Fedora
Component: python-sqlite2 (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dawid Gajownik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-04-24 07:24 EDT by Malcolm Tredinnick
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-24 20:24:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Malcolm Tredinnick 2006-04-24 07:24:54 EDT
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:

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
Comment 1 Dawid Gajownik 2006-04-24 14:18:38 EDT
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
Comment 2 Malcolm Tredinnick 2006-04-24 20:24:38 EDT
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

--> 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).
Comment 3 Andrew Finch 2007-10-31 06:23:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.