A short history of providing Chromium on Slackware.
I have scripted the compilation process in such a way that you can compile the Chromium sources into both chromium and chromium-ungoogled packages for Slackware using the same chromium.SlackBuild script. I compile the packages on Slackware 15.0 and use the same resulting package for both Slackware 15.0 and -current. This is a simple matter of economics – it takes half a day to compile a single package and when I can only validate and run in the evenings, every compilation effectively takes one full day.
The Google developers themselves compile these same Chromium sources into the official Chrome browser binaries using modified, customized versions of the Clang and Rust compiler toolchains to do so. They ship 64bit binaries of both those toolchains inside the Chromium source code tarballs, for both X86 and ARM architectures. No 32bit binaries have been included for a long time now. All of these binaries have been built on a somewhat older Debian release so that they are compatible with modern distros and just work.
As a Chromium packager, I can use these embedded binaries to ensure that I won’t run into source code incompatibilities, but then that only works for 64bit packages. For the 32bit packages I have always been relying on Slackware’s own 32bit versions of Clang and Rust as shipped with Slackware itself. Pat has been so kind to provide recent versions of llvm, rust and rust-bindgen for Slackware 15.0 in its ./extra and ./testing subdirectories, and he keeps doing that until today. Probably because he needs these to compile Mozilla Firefox 🙂 But hey, I profit.
Compiling Chromium using the Slackware native compilers has its own challenges but I have always found ways to deal with that.
Until now.
To compile the Chromium source code, Google has introduced a new tool, crubit, which aims to integrate the C++ and Rust ecosystems. It is a bidirectional bindings generator for C++ and Rust. In the Chromium 152 source code, only the “cc_bindings_from_rs” tool of crubit is being used, but in future also the reverse bindings counterpart “rs_bindings_from_cc” will be added.
The problem I have with this, is that Google compiled this “cc_bindings_from_rs” tool on a modern (Debian?) distro and thereby introduced a dependency on glibc 2.34. Slackware 15.0 contains glibc 2.33 and there you have it. The “cc_bindings_from_rs” program refuses to run on Slackware 15.0.
I have spent considerable time trying to compile crubit on Slackware 15.0 using either the Slackware native compilers or even Google’s own embedded compilers inside the Chromium source code, and have failed to produce a binary that works on Slackware 15.0.
Other measures were required.
The challenge I faced is two-fold:
- I cannot use the embedded “cc_bindings_from_rs” on Slackware 15.0
- I cannot compile a native Slackware version of it either
And these have multiple consequences. I can try to find a way to make that program run on Slackware 15.0 but it’s still a 64bit binary so I cannot solve the problem for the 32bit Chromium anyway if I cannot compile a native 32bit binary for “rs_bindings_from_rs“.
The way I tackled this is as follows. First I extracted a Slackware-current 64bit “aaa_glibc-solibs” package into the filesystem of my Slackware 15..0 compile box:
mkdir -p /opt/glibc-current/lib64 tar -C /opt/glibc-current/ -xf aaa_glibc-solibs-2.42-x86_64-2.txz cd /opt/glibc-current/ rm -r install sbin usr mv -i lib64/incoming/* lib64/ rmdir lib64/incoming
This is a one-time action. These files will remain there for future compilations. And now I have all of the newer glibc libraries (libc.so.6 and others) and the loader (ld-linux) that I need for Chromium, conveniently out of the way so that they do not affect the Slackware 15.0 system.
Then I need to convince the “rs_bindings_from_rs” tool to look at “/opt/glibc-current/lib64/” when it wants to load glibc libraries. For this purpose, I added the following block inside the chromium.SlackBuild script.
# ---
GLIBC_COMPAT=${GLIBC_COMPAT:-/opt/glibc-current/lib64}
RUSTTC="$TMP/tmp-$PRGNAM/${SRCNAM}-${VERSION}/third_party/rust-toolchain"
CBFR="${RUSTTC}/bin/cc_bindings_from_rs"
if [ -x "$CBFR" ] && ! "$CBFR" --help >/dev/null 2>&1 ; then
echo "-- Wrapping cc_bindings_from_rs to use $GLIBC_COMPAT."
mv "$CBFR" "$CBFR.real"
cat > "$CBFR" <<EOF
#!/bin/bash
exec $GLIBC_COMPAT/ld-linux-x86-64.so.2 \\
--library-path $GLIBC_COMPAT:$RUSTTC/lib \\
"$CBFR.real" "\$@"
EOF
chmod +x "$CBFR"
"$CBFR" --help >/dev/null 2>&1 && echo "-- cc_bindings_from_rs OK." \
|| { echo "-- ERROR: cc_bindings_from_rs still not runnable." ; exit 1 ; }
fi
# ---
What this does, is check whether the “cc_bindings_from_rs” tool actually runs (on Slackware-current it will run without issue) and if it fails because of the missing glibc symbols, create a wrapper script which ensures that the newer glibc libraries take precedence over Slackware’s own glibc, only for this particular binary. If “cc_bindings_from_rs” still fails to run, the script will abort.
This solves issue number 1. But for a package build on 32bit Slackware 15.0 I would still need to be able to compile a native 32bit “cc_bindings_from_rs” and that’s simply not possible right now.
The solution here, is to use the 64bit toolchain embedded in the Chromium source, just like I did for the 64bit Slackware package, but then using cross-compilation on a 64bit multilib Slackware 15.0 host with 32bit as the target architecture.
Guess what… the chromium.SlackBuild is already fully prepared to perform a cross-compilation. All it needs is that you set the variable CROSS32 to the value “YES”. The Clang and Rust toolchains that are embedded in the Chromium source code are fully capable of cross-compiling. You do need to turn your 64bit Slackware host into a full multilib system following the instructions.
The command-line that compiles a 32bit chromium-ungoogled package then becomes:
CROSS32=YES BUILD_CLANG=1 USE_UNGOOGLED=1 ./chromium.SlackBuild
Hope this helps if you want to try this yourself and have been struggling with the new requirements.
Cheers, Eric
Eric, As I have neither the patience nor the energy to compile Chromium or LibreOffice, thanks for your effort to create these packages. Much appreciated. Working as expected on 15.0.
Hi.
As always, thanks for your work.
I have unusual request regarding chromium. Did you have saved chromium in at most version 145, and will you share it somewhere? It seem chrome(ium ?) since 146 drops support for OpenGL 2.X and after update to 153 I lost hardware acceleration on one of my systems. I know, it is security risk, but I prefer this than slideshow in YT.
Hi Konrad,
You can download the last Chromium 145 package from here until 20260917: https://alienbase.nl/test/chromium/
I will remove it in 48 hours.
Thank you very much. Downloaded, you may remove it already.
Thanks again. Installed, and working, but not without problems. I tried downgrade chromium before, but it silently crashed. Same was now, but I was more determined to fix it. Deleting whole ~/,config/google-chrome directory isn’t solution – loosing all browsing convenience data will be painful. I try remove one by one elements of ~/,config/google-chrome/Default/ directory an finally pinpoint troublesome dir. It is “~/,config/google-chrome/Default/Sync Data”. After deleting it older chromium starts without problems. And it seems be rather unimportant – sync data for goggle account.
So in conclusion, if you have problem with crashing chromium after downgrading. Just delete “~/,config/google-chrome/Default/Sync Data” directory, and it should work.
Hi Eric,
Thanks for your effort and time consumed keeping these packages up to date for slackware15.
Yea, Google has issues with generating their tarballs for the 153 releases. This is the second time that I am waiting for 3 days already for the source tarball to appear, while there’s a truckload of security fixes that are addressed by the new release.
In the meantime, there’s a new update, 153.0.8010.52, with two critical fixes.
Chromium-ungoogled already updated their patches. Could you not use their method to get the sources?
No. If Google cannot get their act together, and does not respect its packagers, this packager does not respect Google right back.
So, if I understand it correctly, you’re not using your selfmade script as an alternative, or does it not work anymore?
https://blog.slackware.nl/chromium-source-tarball-availability/
It does not currently work.
I’m beginning to suspect Google is changing build requirements and source/tarball availability all the time just to fuck people up who wanna build their own version of Chromium.
Could be true 🙂
In the meantime I opened a post on the chromium-packagers Google group to draw attention to their build infrastructure failure.
This was my thinking. You can’t embed God knows what in source people build for themselves with a transparent build process. but then they start making it just too much trouble for people (or distro maintainers) to build, so people are forced into using prebuilt binaries… it’s enshitification.
And thanks to Eric for fighting against it for so long!
Meaning Google can’t embed whatever. Sorry if it were unclear!