Question

I have a weird problem. 

I am working on a shared library, written using C and a GUI application written on C++. GUI application uses the shared library. This shared library uses SQLite amalgamation and links statically. GUI also uses SQLite for some configuration purpose. It is also statically linked. Both of them uses latest SQLite version. 

My shared library uses FTS4. I have enabled FTS4 by providing the compile time options while compiling the shared library. All works well with the shared library. All my tests in the shared library codebase is passing.

Problem happens when I start using this in the GUI program. I am getting error like, Unknown module FTS4. This is weird because I have it linked statically in my shared library and all this GUI program does is to dynamically link to my library. When I set the FTS compilation options to the GUI program, error goes away and all works well.

In short,

libfoo.so – Statically links SQLite with FTS4 options turned on
foo – Statically links SQLIte with out any special compile time options. Dynamically links to libfoo.

I am not sure why this is happening. Any help would be great!

Answer 1

It sounds like all the sqlite functions in the shared library are being exported. As a result, when you load the shared object, all of these functions get resolved to the main application, which also defines identical copies of the symbol names, but with different functionality.

You may have better luck compiling your shared object with a map file looking something like:

{
global:
  *;
local:
  sqlite3*;
};

put it into a file called foo.map, and when linking libfoo.so (assuming using gcc)

gcc -Wl,--version-script=foo.map -o libfoo.so <dependent files>

This should hopefully cause the use of the internal symbols within the .so rather than the ones defined in the main application.