GNOME Bugzilla – Bug 642100
Library Search Order Sometimes Fails to Load correct libsqlite3
Last modified: 2012-04-28 00:04:30 UTC
Created attachment 180645 [details] patch to file gda-symbols-util.c Please find attached a patch to help resolve a problem loading the sqlite 3 shared library. function: find_sqlite_library () file: libgda-4.2.3/libgda/sqlite/gda-symbols-util.c This function currently starts by searching for sqlite3 library using g_module_open() which usually finds the first instance of libsqlite3.so that's in the cache. However, unfortunately on some systems, there are multiple versions of this library - in this case coming from xulrunner (on Fedora 14) and this version can sometimes be found and loaded first, which if incorrect will cause the above function to fail and ABRT My patch (attached) changes the order of searching to start withe the compile time setting SEARCH_LIB_PATH (e.g. would be /usr/lib64) and then try using g_module_open () This would allow system builders to ensure that any incorrect versions of sqlite3.so (i.e. not part of the system setting) can be bypassed and the search to start in the system lib folder.
Patch applied: http://git.gnome.org/browse/libgda/commit/?id=7cec21afed79479b1e9fbf1637265e9a54e46e7a thanks! BTW, this is not related to the SQLCipher database provider which does not load any DLL at runtime because it uses a static version of SQLite patched to contain the SQLCipher's own code.