[infogulch]

mattn's sqlite3 is probably the most ideal use case for cgo imaginable. But it can still be annoying to set up cgo to build across many platforms.

I think Go should just pull a Zig and just embed a full blown C compiler into go build.

[kunley]

Yeah, once I was on windows and couldn't get cgo sqlite working on a variety of mingw and alike compilers... felt like 90s.

Using this cznic's pure-Go sqlite saved the day.

[oefrha]

Pulling a zig isn't going to solve all problems, as the zig cross compiler itself runs into problems fairly often. I already use CC='zig cc -target x86_64-linux-musl' (or whatever the target is) with cgo to cross-compile mattn/go-sqlite3, and relatively recently it simply stopped working[1] and a workaround had to do be added to about every single project of mine using SQLite through cgo.

I also once tried to figure out a way to cross compile mattn/go-sqlite3 to 32bit Windows with zig, and failed.

The best way to make cross compiling painless is to not use cgo at all. Which is why I use modernc/sqlite whenever possible now.

Btw, bundling a C compiler is also much harder when you don't build on top of LLVM.

[1] https://github.com/mattn/go-sqlite3/issues/1164

[hnlmorg]

I’m going to add a counter argument to all the cgo views raised:

Personally I’ve had much more portability problems with a lot of the native Go ports of sqlite than I have with mattn’s cgo library.

I author a shell that targets most of the architectures and platforms supported by Go. At the request of some users, I added support for a Go native library because they didn’t want to install a C compilers as well as a Go compiler. I tried a few different sqlite ports (though off hand cannot recall which ones) and they all had massive limitations, like only compiling on Windows and Linux (in one example).

In the end, I gave up and reverted back to the cgo version with the option for other libraries hidden behind a compiler flag.

I found my build pipeline manages just fine with cross compiling and haven’t had any complaints (thus far) with the binaries bar one individual running an ancient version of CentOS.

Maybe I’ve been trying the wrong sqlite ports. But here lies the problem: with cgo I know I’m getting a stable, tested, library. With other ports it’s entirely a lottery with regards to how well maintained and tested it might be. For personal projects that’s a fine risk to take but for any larger open source (or even commercial) projects, that additional uncertainty is a risk that distracts me and the other contributors from working on the core part of the project. And thus defeats the connivance of using 3rd party libraries.

[ncruces]

Can you say more, like name your project?

I'm building https://github.com/ncruces/go-sqlite3 and am a community maintainer of https://wazero.io

I can cross compile SQLite into all platforms that Go OOB compiles too, with the caveat that any that aren't linux/windows/darwin/freebsd/illumos (CPU architecture doesn't matter) need a build flag because of file locking: https://github.com/ncruces/go-sqlite3/blob/main/vfs/README.m...

Anything that helps me test portability, or any feedback you might have on it, would be greatly appreciated.

[hnlmorg]

Sorry, just seen this. It is https://murex.rocks

sqlite3 only needs to run from one thread in my use case. Which might explain why I have fewer problems than most.

[hnlmorg]

Just reread your comment and realised I was confusing your library with mattm’s library of the same name.

[ncruces]

Interesting project, thanks for getting back!

My SQLite bindings should build/work fine for all your supported platforms, with the caveat that BSDs other than FreeBSD need a build tag, because my locking protocol is not compatible with SQLite's default (if you access your database concurrently with my wrapper and other SQLite processes, you may corrupt data).

Solaris and Plan9 don't have working file locking, so you can't use concurrency at all. This could be change if there was interest in it.

[scosman]

Exactly. Good to know I didn’t miss a trade off in the mix.

If I’m choosing to use a C framework (SQLite) I’m okay signing up for the environment costs. Prefer that over abstractions in an intermediate layer that might not be maintained in a few years.

[scosman]

Just for the record, had to compile sqlite in gomobile literally the day after this comment and it was a big pain . But got it working and sticking with this approach.

[pram]

Didn't it? Isn't that what 5c, 6c, and 8c were.