[go-nuts] Definitive SQLite integration guide?

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

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

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.