[feature] support more architectures

[nikkicoon]

Is your feature request related to a problem ?

I'm maintaining the package for gotosocial in pkgsrc. It is limited to amd64/x86_64 (at least for NetBSD and FreeBSD, https://gitlab.com/cznic/libc/-/issues/15 , https://gitlab.com/cznic/libc/-/issues/12 , https://gitlab.com/cznic/libc/-/issues/11 ) because of the sqlite implementation being used, if I remember this correctly.
Would moving away from this implementation and supporting more architectures something you'd consider (or alternatively, what else is blocking you)?

[NyaaaWhatsUpDoc]

I don't think we would consider moving away. It's the only Go-only SQLite implementation I'm aware of, and having tried using one with CGO bindings (issues with CGO aside) there's definitely differences between the two causing issues with the way we use the connection concurrently.

However one thing we could consider is supporting build-tags that build a binary with SQLite + PostgreSQL support, SQLite only, PostgreSQL only. Which might solve this situation in some way.

[daenney]

Looking at the cznic/libc repo, it seems support for most of the *BSDs has landed in some initial form, but it got stuck about a year ago. One potential alternative could be something like sqld. It does require running sqld but it allows you to access the SQLite DB using the pg wire protocol. That might be enough so that we can use pg-only in GtS. It would also allow moving away from the current ORM if that's a thing we still want.

That way, we could drop the dependency on modernc.org/sqlite and their C-to-Go compiler, which would potentially allow for supporting all GOOS/GOARCH combinations Go itself supports.

[VyrCossont]

Would the new WASM SQLite option fix this? See #2863, #2938, #2942

[daenney]

Heh, almost. The WASM build doesn't run on the BSDs yet because a locking primitive that's needed there (for SQLite, not GtS) isn't implemented yet.

But if someone gets around to ncruces/go-sqlite3#85 then yes, I think that would solve the alternative architectures. Wazero (the WASM runtime) is a CGo-free implementation in Go and as such should work for any supported architecture by the Go compiler.

[daenney]

Oh actually, it's fine as long as you run with db-sqlite-journal-mode: "TRUNCATE" when using that build. We default to WAL mode for the journal because it tends to be the one with the least performance impact. But in the mean time that's a way to go about it if you want to package it for the BSDs and not be limited to x86 either. It might be good to carry a patch in pkgsrc if you do that to patch the config default to be on the safe side.

[daenney]

@igalic I think this may also be of interest to you?

[tsmethurst]

Once we switch permanently to wasm sqlite3 we can update our CI stuff to build for additional architectures :)

[daenney]

It's worth noting that the WASM SQLite build, by virtue of going through the wazero runtime, only officially supports 32-bit and 64-bit Intel/AMD and ARM. It's a CGo-free runtime, so it works on anything the Go compiler supports, but performance might not be part of the game.

That's not really a problem for us since we don't support stuff like linux/s390, but this also means that something like openbsd/ppc64 might not work well. The same for any RISCv64 or MIPS targets.

That's no different from using the modernc build which comes with more constraints, so in that sense we're not regressing here.

[ncruces]

Hopefully this helps. Or not. Maybe it's even more confusing. But I tried!