Chromium 121 sources were released yesterday, and as much as I would like to tell you that the Slackware packages are ready, in fact it appears that you will have to wait for them for an unspecified amount of time.
I found out that the build of Chromium now needs Google’s custom version of the Rust compiler, next to Google’s custom version of the Clang compiler. Those Rust and Clang versions are intertwined and Google advises packagers to simply use their own pre-compiled binaries which they provide for download.
You guessed… those binaries are not available for a 32bit OS. Nothing new, and it is for that exact reason that as part of compiling Chromium for Slackware, the complete LLVM toolchain is built from Google’s sources first. For every package I release. Tweaking the LLVM/Clang compilation so that they work for 32bit Slackware took a lot of time – after all, no one at Google tests their sources for 32bit build compatibility. So I patch here and there and every time feel lucky that it still works.
Until today, when I ran into the new Rust requirement. And after the umptiest iteration of a Chromium package build using a variety of changing options, I still fail to even start compiling a Rust binary.
I am taking a break from this to consider my options. My aim is to keep supporting the 32bit Slackware package. I just need to figure out how Google messed this up again and find a way around it. In the meantime, don’t hold your breath – I only have a few hours each evening to do the troubleshooting. A new package will appear when it’s ready.
All the best, Eric
Update 2024-jan-29: I have buillt 64bit packages for Chromium (also -ungoogled) version 121.0.6167.85 and uploaded them to my repository.
Note that I can not currently compile their 32bit versions because until now I have not been successful in building Google’s custom llvm and rust from source. I had to revert to downloading and using Google’s pre-compiled binaries which they only supply for 64bit systems.I am still determined to find a way to compile these llvm and rust compilers from Google’s own sources. But I have no ETA on that unfortunately.
Hi Eric.
Sad to hear this. Hope you find a way to keep this browser alive in Slackware. Thanks for your effort and time invested on this.
Regards. Francisco
Thanks for all you do, Eric.
I’ll be standing by for whatever you decide is the best way to go.
— kjh
I guess aficionados will have to test something else…
I’m still so impressed how you get to fight huge showstoppers, and, in the end, win !
Btw, nice mobile theme !
Well I was holding by breath, takes deep breath…
I appreciate all you do for the Slackware community. I take it this issue also applies to 64 bit. Leave it to Google to mess things up.
many thanks for you your work. hopefully you’ll be able to get it going.
Hi
I’m just asking to learn about it.
What is the benefits to keep 32 bit support? Who or what benefit it with that?
Regards and thanks for your efforts
Maintaining upgradeable for a lot of old computers. Very important for Slackware and Linux I think. Just now I found out my CPU doesn’t support KVM /VT-X extension and so I can only use Virtualization with 32 bit OS Images and only few Linuxes still support 32 bit.
Besides Chromium, thanks for your time and effort you put into Slackware!
Thanks for your efforts on all of this, and for continuing to support 32bit hardware. At some point in the future it may be that the effort required to support 32bit hardware may be outweighed by the number of people still relying on older computers,
You only have so many hours in a day after all.
Thanks 🙂
However my current challenge also affects the 64bit build of Chromium.
I am doing everything I can think of to compile custom versions of clang and rust, so that I can also keep releasing 32bit packages. If in the end I have to revert to Google’s pre-built binaries then all is lost for the 32bit Chromium on Slackware.
Does this contain info that might be useful to you?
https://github.com/ungoogled-software/ungoogled-chromium/pull/2681
The diffs for ungoogled chromium are only meant to update the ungoogled parts. It’s not relevant to my issue which is building Google’s llvm and rust compilers from their customized sources prior to compiling (ungoogled) chromium.
All the other distros just download and use Google’s pre-built compiler binaries, or remove all the new Chromium code which crreates a dependency on those custom compilers, so that these distros can then use their own system-wide llvm and rust versions.
But I am not that smart that I can work out those dependencies, patch Chromium and end up with working binaries, so I have to stick with the compile-from source strategy for as long as I can.
Yeah I know Chromium is not Chrome. But…
I thought Chromium is suppose to be open source software? Are there not rules on Linux when users modify source code they must make those modifications to everyone?
A very old saying — “rules for thee but not for me.” 🙂
You have not understood what I am writing about. This has nothing to do with evil corporations versus open source suckers.
Thanks for the chromium-ungoogled 121.0.6167.85 update!
Nitwit question, does building it with Google’s binaries make the resulting Chromium package less trustworthy, I mean, could these building binaries put code in the resulting package that wasn’t in the source? Is that your reason for wanting to build them yourself? Apart from the need to do that for the 32bit package of course.
I build the compilers myself because Google only provides 64bit binaries and I want to be able to compile 32bit chromium packages.
It has nothing to do with trusting Google’s binaries or not. Do you have an Android phone? You are trusting Google’s binaries.
I have a smartphone (without SIM card) but I don’t put any personal information in there. I download my APK’s, but I avoid using apps, if I can. For calling I use a feature phone.
I thought you had other reasons because you apparently also build the 64bit compilers.
Why would I create two different SlackBuild scripts for 32bit and 64bit?
When creating Slackware64 I have rewritten all of the official Slackware build scripts so that each single script can build for multiple architectures. I am not willing to change that strategy now.
I think we misunderstand each other.
I thought it was possible to run into different problems building the same package for different architectures. And it’s not only about the scripts, it’s also the time it takes to build them.
Anyway, nevermind, I was just curious, I don’t want to take more of your time.
Building for 32bit (Chromium and other software) usually has its own problems to solve. In the case of chromium, I need to make sure whether the problem I am trying to solve is in Chromium or in the compilers that I just built.
On 64bit I can usually solve issues quickly, so I build first on 64bit and if I have a working package, I repeat on 32bit. This necessitates that the same SlackBuild script builds these compilers on 64bit (where I also could have taken Google’s binaries) as well as on 32bit.
As I stated in the past on occasion: if I can avoid 3rd-party binaries I will do so.
Thanks! I understand now. One more question then, has Google got a reproducible builds policy? In other words, if you build the compilers from Google’s source in the same environment with the same arguments, are the resulting binaries the same as Google’s binaries? If you never tried or thought about this then never mind, I will try to find out myself. Maybe you’re finding me a pain in the ass by now. 😛
I compile them on Slackware, that definitely counts as “not the same environment” 😉
The whole point is native build. I could not care less about reproducible builds tbh.
Thanks for the chromium-ungoogled 121.0.6167.139 update.
Hope you’re feeling better already.
By the way, did the Google build binaries run out of the box in your environment or did you have to use some trickery with libraries and stuff?
Google’s pre-built clang and rust compilers run out of the box on Slackware.
The story is more complex when you look at how Google builds Chromium with as little possible external dependencies. When you examine the SlackBuild, a lot of tweaking is required to use the Debian “sysroot image” – not because of the binaries contained inside that sysroot image, but because headers and libraries are in places Slackware does not expect and I have to fix that with symlinks and such.
Thanks for the chromium-ungoogled 122.0.6261.57 update!
Thanks for the chromium-ungoogled 122.0.6261.128 update!
Chromium-ungoogled 123.0.6312.58 update!
Much obliged!
Thanks for the chromium-ungoogled-123.0.6312.86 update.
Chromium-ungoogled 123.0.6312.105 available. Thanks!
Chromium-ungoogled 123.0.6312.122 update. Thanks!