Chromium 152 sources contain another major step for Google to unify their build infrastructure. Great for Google but for me it sucks.
Because unfortunately for me (and for you, the Chromium browser user) Google introduces new tools as part of their custom Rust toolchain that I am unable to compile locally as Slackware-native binaries. The “cc_bindings_from_rs” tool biting me in particular, part of the “crubit” project, also from Google.
Which means that (for now) I have to use the pre-built LLVM and Rust toolchain binaries that are embedded in the Chromium source tarball.
There’s a big ‘gotcha‘ to that now, something that was never an issue before. They have built “cc_bindings_from_rs” on a system that is more modern than Slackware 15.0, so that this binary (and also several others as I found out) fail to run on Slackware 15.0, complaining “version `GLIBC_2.34′ not found“. As a result, the chromium.SlackBuild script fails to produce a package.
For the time being, I refuse to ditch support for Slackware 15.0 and I will keep trying to find a way to compile Chromium 152. This is galling, because I would like to spend my precious time on actually useful stuff instead of fighting Google at their own game. Still, the amount of CVE’s that is addressed by Chromium 152 is huge and I cannot ignore that.
Then LibreOffice is adding insult to injury. You might have seen in my repository’s ChangeLog.txt that I only released LibreOffice 26.8.0 as 64bit Slackware packages (15.0 and -current). I can not make the 32bit compile work here. An issue (looks like a compiler trap) which is unrelated to the Chromium problem, but it shows a troubling trend: the disregard that developers have for users of older 32bit hardware and older Operating Systems. The build of this new release simply was never properly quality-tested on 32bit.
To be continued.
Update 20260830:
For 32bit Chromium I found a solution which I documented in a separate blog article.
For 32bit LibreOffice I also found a fix, which boils down to “make sure that clang does not run out of address space on a 32bit host”. I disabled debug symbols, reduced code compilation optimizations, cranked up the stack limit and reduced the parallelism from “use all your cores” to “just four, no more”. All of this combined has indeed helped clang avoid traps and segfaults. Takes a lot longer to complete but that’s the compromise.
Sad to see this. Wish this would push Pat towards a fresh -stable release. We do need such a release with latest gcc, glibc, maybe python-3.12 (or later?)
I do hope you’ll manage to solve the chromium issue.
glibc-2.42 is available in /slackware64-15.0/testing/packages/ and it seems as if more and more -stable users have chosen that option. Have you considered to build a -15.0 package against that, placed in your own /people/alien/testing ?
Yeah, I second that. Currently, releasing a new stable with also updated Qt, KDE, Vulkan, FFmpeg and OpenSSL, amongst others, seems logical.
There are a lot of programs where new versions (qBittorrent for instance) are not working on 15.0, and building everything myself is a PITA.
I can’t wait to see a new stable release 🙂
Good luck with compiling 152 by the way!
Does this contain useful information?
https://github.com/ungoogled-software/ungoogled-chromium/pull/3928
That’s only part of the story, and yes I have already incorporated the proposed patch in my SlackBuild script.
I have already uploaded a 64bit Chromium 152 package and the Un-Googled package will follow soon.
Oops apologies, I had not pulled the trigger yet. Now uploading.