[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?