Hello,

Would it be possible to have precompiled binaries produced for arm64 as well?

I believe it would be beneficial to all those Raspberry Pi owners that would like (or need) to run a more up-to-date version of SQLite on their Raspberry Pi OS (Debian 12 at the time of writing).

Thanks

Would it be possible to have precompiled binaries produced for arm64 as well?

There is no One True Build for arm64. SQLite needs to be compiled for the target OS (or a very close work-alike), not the target hardware platform, and there are many different OS flavors for arm64. An arm64 binary built for my pi5 won't run on Windows-on-Arm64.

I believe it would be beneficial to all those Raspberry Pi owners that would like (or need) to run a more up-to-date version of SQLite on their Raspberry Pi OS (Debian 12 at the time of writing).

SQLite is trivial to build oneself and users of "maker" boards, like the Raspberry Pi, tend to be technically savvy enough to compile software.

SQLite is trivial to build oneself

I really need to update the linked document. I just checked in some changes to the "Overview" section and uploaded them, but the whole thing needs a rewrite. I'll (hopefully) get that done over the next few days.

There is no One True Build for arm64. SQLite needs to be compiled for the target OS (or a very close work-alike), not the target hardware platform, and there are many different OS flavors for arm64. An arm64 binary built for my pi5 won't run on Windows-on-Arm64.

Fair point, then I guess my request would be for linux/arm64.

SQLite is trivial to build oneself and users of "maker" boards, like the Raspberry Pi, tend to be technically savvy enough to compile software.

I agree with you on this as well, but at the same time I think it's also true that providing a precompiled/ready version would make those users life easier anyway (i.e. I am technically savvy enough to compile software, but I rather use the precompiled version of the browser I'm writing this reply with than compiling it by myself). I'm not saying this is or has to be a priority, I just wanted to politely ask in case there was an interest from the maintainers to make linux/arm64 a first class citizen (for the SQLite Download page that is).

I rather use the precompiled version of the browser I'm writing this reply with than compiling it by myself

That is not a fair comparison. Compiling a web browser takes a long time even on a beefy machine and requires installing a huge collection of dependencies before you even begin. Compiling SQLite, on the other hand takes a few seconds and does not require any dependencies. If you have "build_essential" installed on your linux/arm64 machine, then you can compile SQLite with just "./configure && make"

I don't think there is a huge difference between AMD64 and ARM64 in this regard.

A Debian oldstable or Alma/Rocky oldstable (for glibc compatibility reasons) based ARM64 build would be very widely usable.

Regarding the glibc compatibility, actually the AMD64 binaries available on sqlite.org do not run on Debian stable, because they require glibc 2.38 : https://sqlite.org/forum/forumpost/e01eabc6e71c98ef947d5b5012c04773c63ceb026053db6fa6245a26ca06c590

Whether it's a good investment of the developers time to provide more architectures and better glibc compatibility is probably subjective.

I spin up an Ampere instance on Hetzner with Debian oldstable to build binaries for my Pi's, that's fast and I don't need to keep the build environment around.

Whether it's a good investment of the developers time to provide more architectures and better glibc compatibility is probably subjective.

I don't think it is worth the effort. but there is a solution. The Python world has the same problem with binary extensions which need to be appropriately compatible with various glibc and musl versions on various architectures. They have produced manylinux which are available as docker images. You can see what that provides.

My Python extension includes the SQLite amalgamation inside, so it does all work. But it also results in a stupendous list of binaries covering all the Linux, Windows, and Mac variations.

The much simpler solution is like I said a supported but not bleeding edge operating system.

The manylinux folks list what they use and compatibility which is Alma for recent builds. If you have a Linux host it turns out quite easy to use those container images for several platforms with qemu emulation and podman container engine.

One time setup

Python builds use tonistiigi/binfmt. An alternative is multiarch/qemu-user-static. They provide the qemu binaries and configure binfmt_misc to recognise the non-host platform binaries and use qemu to emulate them.

sudo podman run --rm --privileged docker.io/tonistiigi/binfmt:latest --install all

Edit tonistiigi/binfmt is known good as many Python packages are built and deployed using it. As an alternative your Linux distro may have a package named something like qemu-user-static which provides the same functionality and can be installed instead.

Do a SQLite build

This assumes that the SQLite source is in a sqlite3 subdirectory of the current directory. The image names and compatibility are listed here. The last line is what is executed inside the container.

arm64

podman run --rm -v `pwd`/sqlite3:/project --platform linux/arm64 \
    quay.io/pypa/manylinux_2_34_aarch64 \
    sh -c 'cd /project && ./configure && make && make test'

s390

podman run --rm -v `pwd`/sqlite3:/project --platform linux/s390x \
    quay.io/pypa/manylinux_2_34_s390x  \
    sh -c 'cd /project && ./configure && make && make test'

Getting a shell

Use the same run commands, but add -i --tty to the podman arguments and replace the last line with bash -i.

One time setup

The cross-compatibility helpers are increasingly becoming part of the platform, saving you the necessity of setting it up manually.

The biggest segment where this is true is on non-Linux hosts, where Podman and Docker require a canned background VM, which includes these tools inside the OS image.¹

This is happening increasingly on Linux hosts as well, part of the "containerization eats the world" trend. One place you can see this is in Fedora Silverblue, where the following command works out of the box on an Intel host:

$ podman run --rm -it --platform linux/arm64 alpine uname -m
…
aarch64

For those not following the sleight-of-hand behind all this, that command pulls an AArch64 version of Alpine and runs it on an Intel box, transparently. There is no setup necessary to achieve the result because Silverblue is a container-first OS that tries to preinstall everything you need to support that, to avoid excess layering.

tonistiigi/binfmt is known good as many Python packages are built and deployed using it.

It's not limited to the Python world. Docker, Inc. recommends it in their own multi-platform doc.

I prefer to use with the OS platform's qemu-user-static package when it's available, though, especially when I get podman that same way.

-i -tty

That needs to be either -it or --interactive --tty or some combination. (Two dashes on long options, not one.)

1. ^{^} This is a recent development in the Podman world, but Docker's been doing it for a long time.

Another option you might like is Distrobox:

$ distrobox create \
    --image debian \
    --additional-flags \
    --platform=linux/aarch64 \
    debian-aarch64
$ distrobox enter debian-aarch64
⬢ $ uname -m
aarch64
⬢ $ sudo apt update && sudo apt install build-essential
⬢ $ cd ~/sqlite3 && ./configure && make && make test

That sets up a Debian 12 aarch64 (i.e. Pi-compatible) dev container with your host-side $HOME mapped in, which is why the final command succeeds without an explicit --volume flag.

The beauty of this is that you don't have to recreate the container each time. You just give the "enter" command again.

Beware that because this shares the build tree (~/sqlite3) with the host, you should make clean when switching architectures like this.

If the "enter" step appears to get stuck on installing the "basic packages" the first time, it's because it's running through emulation. Be patient.