Definitive SQLite integration guide?

[Maxim Khitrov]

Hello,

I've read all the discussions that I could find on this topic, but I'm
still confused about the status of compilation or static linking of
SQLite. In the end, I'd like to have an executable that can open and
work with SQLite databases. It doesn't really matter whether this is
accomplished through cgo or some other method. Is there a way of
either compiling the SQLite amalgamation source directly into a Go
executable, or building it separately and then linking in the static
library, which works on Linux, BSD, OS X, and Windows?

If this is possible, could someone write a short guide for all of
these systems describing the steps from having a Go 1.0.3 installation
and SQLite amalgamation source to building an executable that can
interact with a SQLite database?

- Max

[James Cooper]

Hi,

Have you tried this package yet?

https://github.com/mattn/go-sqlite3

The included example shows basic usage:

https://github.com/mattn/go-sqlite3/blob/master/example/main.go

cheers

-- James

[Maxim Khitrov]

I have, but the following line didn't make much sense to me:

"Go does not support static linking for external C library; sqlite3
should be built as a shared library. If it runs on Windows, it needs
dll."

After sending my message, I took rsc's implementation of the sqlite
interface, added the fix for the undefined ___chkstk_ms [1] (didn't
need to change LDFLAGS), and was able to compile the amalgamation
source directly into the Go binary. I didn't do much testing with it,
but creating a new database and a few tables seemed to work fine. On
FreeBSD, I ran into a bunch of "unhandled relocation" errors, but
didn't have enough time to diagnose the problem. I'm probably
misunderstanding something about the current support for compiling C
code directly into a Go binary and linking in a static library.

My point is that getting SQLite to work with Go seems to be a bit of a
black art at the moment. There are discussions about reimplementing
the vfs layer, though I don't really understand what that's for. There
is some wrong or outdated information on the mailing list; issues that
may have required fixes 2 years ago, but not with the current version
of Go. Given how popular SQLite is for any applications requiring more
than plain text file storage, I think it would help many people to
have one definitive guide that describes the recommended practices for
getting SQLite to work with the current version of Go on various
platforms. Static linking would be better if it's possible to do, but
that's just the thing - I can't figure out what is and isn't supported
at the moment.

- Max

[1] https://groups.google.com/d/msg/golang-nuts/VNP6Mwz_B6o/hhgIbxzdCQwJ

> --
>
>

[Guillermo Estrada]

I think you are right, but not only in regards to SQLite, but to every other C library out there, especially on Windows. Most of the times you have to do black magic, install a C toolchain have dependencies of libraries to build those libraries, all in C with MinGW, but oh wait... 64 bits? Let's roll back. All and all its painfull to have to do all that. I've expressed this before in tis group and a lot of Windows developers are really frustrated about it, if you want to use OpenGL, or FreeType, or SQLite or XXXXXX library, you have to go all through a complicated process to be able to statically link the library to your program instead of what every other programming language does out there, go to the webpage, download the prebuilt binary dll, have some (or write yourself) bindings/wrappers/api whatever you want to call them to the library written in your language (not in C) and just compile and run everywhere as long as you provide the Dynamic Library with your executable binary.

Someting like Derelict for D, or even better, FFI library for LuaJIT. Automatic code generation to interface C libraries I think its the way to Go! I actually started programming in Go to get away from C, funny how that turned out.