Linking libsqlite statically

[D. Kettler]

Hello,

I've written a simple C++ app which uses sqlite and thus far it works
perfectly fine as long as I compile it linking to the library dynamically
(standard g++ behavior). However, I would like to be able to distribute
this app to people who do not necessarily have the sqlite libraries
installed, and so I want to link the sqlite libraries statically.

When I add the -static flag to my g++ command it gives me 'undefined
reference to' errors for every instance where I attempt to use a sqlite
function.

This is on a Debian (testing) system and yes I have both libsqlite3 and
libsqlite3-dev installed. There are libsqlite3.a, libsqlite3.la, and
libsqlite3.so files in /usr/lib/

I also tried giving the path to the libsqlite3.a file explicitly, but it
works no better.

Any thoughts? Thanks.

--
David Kettler
***@u.washington.edu

[Aaron Schneider]

Post by D. Kettler
When I add the -static flag to my g++ command it gives me 'undefined
reference to' errors for every instance where I attempt to use a sqlite
function.

If you compile and use the header files from the projects, they will add
a __declspec(dllimport) to the beginning of the files. In Visual
Studio, this changes the symbol defs, so functions used in your linked
code will not work.

To fix it, just change the "#define SQLITE_EXPORT __declspec(dllimport)"
to "#define SQLITE_EXPORT" near the top of sqlite.h.

HTH,
Aaron

[D. Kettler]

Post by Aaron Schneider
If you compile and use the header files from the projects, they will add
a __declspec(dllimport) to the beginning of the files. In Visual
Studio, this changes the symbol defs, so functions used in your linked
code will not work.
To fix it, just change the "#define SQLITE_EXPORT __declspec(dllimport)"
to "#define SQLITE_EXPORT" near the top of sqlite.h.

Project? DLL? Visual Studio? I said I was using Linux and g++

--
David Kettler
***@u.washington.edu

[Curtis King]

Post by D. Kettler
Project? DLL? Visual Studio? I said I was using Linux and g++

just link with full path to libsqlite3.a

example: gcc -o foo foo.o /usr/local/lib/libsqlite3.a

man gcc

ck

[Aaron Schneider]

Post by D. Kettler

Post by Aaron Schneider
If you compile and use the header files from the projects, they will
add a __declspec(dllimport) to the beginning of the files. In Visual
Studio, this changes the symbol defs, so functions used in your

linked

Post by D. Kettler

Post by Aaron Schneider
code will not work.
To fix it, just change the "#define SQLITE_EXPORT
__declspec(dllimport)" to "#define SQLITE_EXPORT" near the top of
sqlite.h.

Project? DLL? Visual Studio? I said I was using Linux and g++

I know you're not using Visual Studio. But I'm guessing that g++ does
something similar. Make sure that the macro SQLITE_EXPORT is not equal
to __declspec(dllimport), recompile all of the object files, and see if
that works.

[D. Kettler]

Post by Aaron Schneider

Post by D. Kettler

Post by Aaron Schneider
If you compile and use the header files from the projects, they will
add a __declspec(dllimport) to the beginning of the files. In Visual
Studio, this changes the symbol defs, so functions used in your

linked

Post by D. Kettler

Post by Aaron Schneider
code will not work.
To fix it, just change the "#define SQLITE_EXPORT
__declspec(dllimport)" to "#define SQLITE_EXPORT" near the top of
sqlite.h.

Project? DLL? Visual Studio? I said I was using Linux and g++

I know you're not using Visual Studio. But I'm guessing that g++ does
something similar. Make sure that the macro SQLITE_EXPORT is not equal
to __declspec(dllimport), recompile all of the object files, and see if
that works.

But I'm using the libraries that came with my distribution. I didn't
compile them myself in the first place, and I shouldn't have to go editing
system files just to statically link something.

In any event, I checked in sqlite3.h and it doesn't even contain a
"#define SQLITE_EXPORT" line.

--
David Kettler
***@u.washington.edu

[Ulrik Petersen]

Hi,

There are libsqlite3.a, libsqlite3.la, and libsqlite3.so files
in /usr/lib/

Could you show us the exact command line you are trying to use when
running g++ ?

I'm especially interested in the version where you give the
/usr/lib/libsqlite3.a fully qualified filename on the commandline.

You might be interested in an introduction to doing static/dynamic
libraries on Unix, written by Dr. Kirk Lowery:

http://emdros.org/progref/page.php?pid=1080


Ulrik P.

[D. Kettler]

Post by Ulrik Petersen
Hi,

There are libsqlite3.a, libsqlite3.la, and libsqlite3.so files
in /usr/lib/

Could you show us the exact command line you are trying to use when
running g++ ?
I'm especially interested in the version where you give the
/usr/lib/libsqlite3.a fully qualified filename on the commandline.

Sure. Linking dynamically with:

g++ -lsqlite3 -o kumacgen kumacgen.cpp

Works fine. I tried:

g++ -static -lsqlite3 -o kumacgen kumacgen.cpp

and

g++ -o kumacgen kumacgen.cpp /usr/lib/libsqlite3.a

Neither of which works. Though the error messages between the two are
different. The first complains about undefined references and the second
seems to have a problem with libsqlite3.a itself, giving the error:

/usr/lib/libsqlite3.a(os_unix.o): In function `testThreadLockingBehavior':
: undefined reference to `pthread_create'

--
David Kettler
***@u.washington.edu

[Curtis King]

Post by D. Kettler
g++ -o kumacgen kumacgen.cpp /usr/lib/libsqlite3.a

add -lpthread to your link line.

ck

[D. Kettler]

Post by Curtis King

Post by D. Kettler
g++ -o kumacgen kumacgen.cpp /usr/lib/libsqlite3.a

add -lpthread to your link line.
ck

Thank you! I should have thought of that, d'oh. Anyway, it works now.

--
David Kettler
***@u.washington.edu

[Aaron Schneider]

Sorry about that. I'm using 2.8.16, and we just changed it to compile
into a lib that is statically linked into the executable (with no DLL) .
I encountered a very similar sounding problem, so I thought I would
offer our solution.

I guess that sqlite3 is organized differently. I just looked and
confirmed that sqlite3.h doesn't seem to have those values defined.

-----Original Message-----
From: D. Kettler [mailto:***@u.washington.edu]
Sent: Monday, August 15, 2005 5:37 PM
To: sqlite-users-CzDROfG0BjIdnm+***@public.gmane.org
Subject: RE: [sqlite] Linking libsqlite statically

Post by Aaron Schneider

Post by D. Kettler

Post by Aaron Schneider
If you compile and use the header files from the projects, they will
add a __declspec(dllimport) to the beginning of the files. In
Visual
Studio, this changes the symbol defs, so functions used in your

linked

Post by D. Kettler

Post by Aaron Schneider
code will not work.
To fix it, just change the "#define SQLITE_EXPORT
__declspec(dllimport)" to "#define SQLITE_EXPORT" near the top of
sqlite.h.

Project? DLL? Visual Studio? I said I was using Linux and g++

I know you're not using Visual Studio. But I'm guessing that g++ does
something similar. Make sure that the macro SQLITE_EXPORT is not
equal to __declspec(dllimport), recompile all of the object files, and
see if that works.

But I'm using the libraries that came with my distribution. I didn't
compile them myself in the first place, and I shouldn't have to go
editing
system files just to statically link something.

In any event, I checked in sqlite3.h and it doesn't even contain a
"#define SQLITE_EXPORT" line.

--
David Kettler
***@u.washington.edu

[Clay Dowling]

Post by D. Kettler
When I add the -static flag to my g++ command it gives me 'undefined
reference to' errors for every instance where I attempt to use a sqlite
function.
This is on a Debian (testing) system and yes I have both libsqlite3 and
libsqlite3-dev installed. There are libsqlite3.a, libsqlite3.la, and
libsqlite3.so files in /usr/lib/
I also tried giving the path to the libsqlite3.a file explicitly, but it
works no better.

David,

Static linking is a major pain in the tail. Everything is dependent upon
the order that libraries are listed on the linker command line. If
something in a module that appears after -lsqlite3 references sqlite3, you
won't get the symbol resolved by the linker.

What's your link command line (the one that contains -lsqlite3)? That may
help us out quite a bit. The earlier bits about #define are malarkey and
only relevant to win32 programmers. They have a notion of private and
public members for shared libraries that doesn't apply in the UNIX world.

Clay Dowling