Bug 189748 - _sqlite.so cannot resolve a symbol when dbapi2.py imported.
Summary: _sqlite.so cannot resolve a symbol when dbapi2.py imported.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: python-sqlite2
Version: 5
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dawid Gajownik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-24 11:24 UTC by Malcolm Tredinnick
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-04-25 00:24:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Malcolm Tredinnick 2006-04-24 11:24:54 UTC
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

Comment 1 Dawid Gajownik 2006-04-24 18:18:38 UTC
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

Comment 2 Malcolm Tredinnick 2006-04-25 00:24:38 UTC
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).

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