Fossil Forum
Post: Minimum glibc for the Linux x86 binary download
The Linux binary download is nice to have when testing and introducing Fossil on shared web hosting.
The current 2.26 and 2.27 support a older version of glibc, while the snaphot (2026-01-28) seems to be build with 2.35 (or 2.38?). Are there any reason for compiling against that version of glibc?
Some share web hosts seems to be rather conservative and use older supported Linux distributions, eg. Debian 11 with LTS until august 2026, which use glibc 2.31.
Would it be possible keep linking to a older glibc, at least until around august 2026?
Would it be possible keep linking to a older glibc, at least until around august 2026?
Are you willing to donate and maintain a machine for that purpose?
Builds are done with what the builder has available.
For as long as it compiles, it shouldn't be hard to continue building your own Fossil binary on Debian 11. You can even keep the build machine separate from the machines you want to run it on, just copy fossil to /usr/local/bin (or wherever you'd like). I already effectively do this on Debian 13 systems, compile on one machine and copy it to multiple hosts I want to use it on.
Builds are done with what the builder has available.
If the machine that build 2.26/2.27 is gone, then it's understandable.
You can even keep the build machine separate from the machines you want to run it on, just copy
fossilto/usr/local/bin(or wherever you'd like)
Yes, I know that. I was thinking more on what binaries was available for download for users that might not have machines that they can build binaries on, and for referencing the download in a recipe like https://få.rødsei.no/wiki?name=Fossil+på+domenshop&p Z
Debian 11 provides Fossil 2.15 and there's pretty good backwards compatibility in the Fossil protocol, I doubt that it's broken. If you really must have a fossil binary, is this not good enough? That'd certainly reduce the installation instruction to apt install fossil.
There's also the point that Debian 11 is now oldoldstable, and probably unlikely to have random desktop users still running it.
Could the following be useful?
If there exist a makelinuxbinary.sh in the debian directory:
#!/bin/sh
apt -qy update
apt -qy install curl perl zlib1g-dev build-essential
apt -qy upgrade
cd /openssl/openssl || exit
./config no-ssl3 no-weak-ssl-ciphers \
no-shared no-threads \
no-tls-deprecated-ec \
--openssldir=/etc/ssl
make -j"$(nproc)" CFLAGS=-Os
cd /fossil || exit
./configure \
--with-openssl=/openssl/openssl \
--disable-fusefs
make clean
make -j"$(nproc)" CFLAGS=-Os fossil
strip fossil
and the following is run in the checked out fossil directory (and OpenSSL exist in $HOME/openssl/openssl):
#!/bin/sh
docker run -ti --rm \
--volume "$(pwd)":/fossil \
--volume "$HOME/openssl/openssl":/openssl/openssl \
-e DEBIAN_FRONTEND="noninteractive" \
amd64/debian:oldoldstable /fossil/debian/makelinuxbinary.sh
Testet on Mac Studio from 2022.
That'd certainly reduce the installation instruction to
apt install fossil.
Yes, but on a shared web host it's not usually possible for users to install packages, but one can run cgi.
Testet on Mac Studio from 2022
Seeing as you have this working, can you not use that approach to build a binary for your shared hoster?