Alien Pastures

My thoughts on Slackware, life and everything

Tag: 32bit

The bit-rot of 32bit Linux

February 8, 2025 / / 19 Comments

Interest of software developers in the use of their product on 32bit Operating Systems has been declining for years. Build tests are only done on 64bit OS’es nowadays. For obvious reasons: there are not so many computers left in the Western world that only support 32bit software.
The thing is, there’s still a lot of old computer hardware in use outside of the wealthy West. Slackware is one of the few remaining Linux distros where the 32bit flavor is just as relevant as the 64bit variant. Yes, you may question the value of running really new software on really old hardware, but I think that is the users’ choice and if you happen to live in a country where a 2025 computer amounts to a year of salary, then I would want also those people to enjoy modern software and security patches.

I can’t recall how many patches have been needed to make source code compile on 32bit Slackware for instance, but in most cases there would be a way to patch the source or circumvent the error. Patrick Volkerding does this for the distro core and I do something similar for the packages in my own repository. And we sigh and complain to each other when compilations fail due to the restrictive 32bit address space, the inability to specify either “lib” or “lib64” as the LIBDIR, the use of architecture-specific assembly code and CPU instructions, etcetera.

But like with everything that’s left to rot in a corner, it’s getting increasingly difficult to keep 32bit Linux alive. I am running into huge time-sucks when packaging complex pieces of software. Specifically, I have not been able to compile 32bit Chromium since the 132 release despite all of my attempts. And now LibreOffice joins that list: I have been unable to compile the 25.2.0 release on 32bit Slackware 15 and -current.

So.
I will give up my attempts to create 32bit packages for future Chromium and LibreOffice releases. It has already taken way too much of the little time I have left after my regular day-time job. If I run into more of these programs that won’t allow me to compile 32bit binaries, those will quickly be added to that list as well.
I will ask again: if there are people among you (readers) who really need their 32bit programs, I need you to come up with the patches to make that work.

As long as there is a 32bit Slackware, I will keep maintaining my multilib repository of course: there’s nothing for me to actually compile there now that gcc and glibc packages in 64bit Slackware support multilib; the work is reduced to simple re-packaging. But once Patrick decides that 32bit Slackware goes the way of the dodo, then also multilib for Slackware will disappear. It would really be a shame though, but there’s simply no longer any kind of movement that is sufficiently influential to be able to sway software developers and keep 32bit Linux instances running to do their unit testing.

Looking at the Wine emulator, that one can be built so that it no longer needs 32bit libraries, but it would lose the capability to run 16bit Windows programs. I guess that’s where DOSbox would come in to save the day.

But be forewarned: the 32bit OS has become an endangered species.

Eric

Respect all little bits

August 11, 2024 / / 17 Comments

I finally figured out how to successfully compile the 32bit version of Chromium (and its un-Googled sibling) on Slackware, now that this requires the Rust compiler to build it. Pat added the final bits that I needed to the rust.SlackBuild script in Slackware recently.

Why did it take so long? Basically ‘real life’ intervened and I did not have time left to investigate.

I assume there may be one or two users left who use my 32bit Chromium package, the rest of you simply don’t care whether I can produce these 32bit packages or not. No one reached out and asked, can I help?
Prime example of slackers, right? It is what it is, and I respect that, and honestly I understand; there’s no fun in having to deal with all these Chromium developer assumptions that everyone uses Ubuntu. Kudos to the Ungoogled-chromium team however – they have been really helpful whenever I got stuck.

The bottom-line is, that I will resume my builds of a 32bit version of Ungoogled Chromium, once per month, for Slackware 15.0 and -current, until the process breaks again and then it’s goodbye to 32bit Ungoogled Chromium.
In any case, there will not be further 32bit packages for the regular Chromium browser going forward. I will remove the existing 32bit chromium packages from my repository because I want to prevent people downloading a vulnerable browser.

Eric

Update – I have uploaded 32bit packages:

+--------------------------+
Mon Aug 12 20:13:12 UTC 2024
chromium-ungoogled: updated 32bit to 127.0.6533.99 (Slackware 15.0 & onwards).
  If your browser keeps crashing with seccomp errors, add this as startup
  parameter: "--disable-seccomp-filter-sandbox".
  For reference: https://alien.slackbook.org/blog/chromium-90-packages-again-32bit-related-issues/

Chromium 90 packages – again 32bit related issues

April 18, 2021 / / 32 Comments

There’s new ‘chromium‘ and ‘chromium-widevine-plugin‘ packages in my repository. And chromium-ungoogled packages will follow soon.

Chromium was upgraded to 90.0.4430.72 but unfortunately the 32bit package which I have built (twice) crashes immediately on startup. This happens both on Slackware 14.2 and on -current. The error message looks like it is something different than the glibc-2.3x related seccomp crash behavior in the previous Chromium 89.x releases.
Since I don’t have hardware that is running a 32bit Slackware OS and could only test on QEMU virtual machines so far, I can not confirm with 100% certainty that the new Chromium will or will not work on your 32bit Slackware OS, which is why I also kept the older 32bit chromium-89.0.4389.114 package in the repository.
Let me know about your experiences down here in the comments section! I am getting tired of begging Google developers not to break 32bit binaries every major release. I’d be grateful if people running 32bit Slackware who are affected by the 32bit Chromium crashes, would chime in. Else I will eventually have to drop 32bit support.

There’s also an updated Widevine plugin package, unfortunately Google only released this newer version for 64bit systems. The new 64bit package has version “4.10.2209.1” whereas the 32bit package remains at version “4.10.1582.2”.
Note that this Widevine plugin is meant for chromium-ungoogled only. The ‘real’ Chromium does not need or use it, since Chromium downloads this CDM library automatically for you.

Have fun!
Eric

Chromium 64 – and 32bit pain

January 29, 2018 / / 7 Comments

The new release of the Chromium sources gives us version 64 of Google’s browser. I have created Slackware packages for you, but that was not entirely trivial.
The Chromium compilation on my 32bit Slackware OS kept failing on the embedded ffmpeg. I am afraid the fact that some of the bigger distros are dropping 32bit variants starts showing and things are coming apart at the seams.
When you are a developer and there’s no 32bit release of your favorite OS, this makes it quite difficult to test the validity of code paths when you only compile and test your code on a 64bit platform. This is what’s happening with Google’s Chromium code and it will probably only get worse.

For now, I could get away by disabling assembly code in the 32bit avcodec library, but in order to get that going I had to study the Chromium code carefully – Google does not use the standard autotools or cmake configurations that the Average Joe would employ when compiling ffmpeg, instead they re-invent the wheel every so often to keep everyone on edge. First it was Gyp, but that did not work out too well and the current fad is called GN (as Google state themselves “GN is a meta-build system that generates Ninja build files so that you can build Chromium with Ninja“).

Some time soon, I need to dissect Chromium’s embedded ffmpeg code, to see if I can get assembly code compiling again on 32bit. Else it may be more prudent to start depending on an external (system-wide) ffmpeg installation, which I can compile without any pain on 32bit Slackware.

We’re fine for now, at least. Let’s hope it does not get worse.

Get your chromium 64 packages for Slackware 14.2 and -current:

Cheers, Eric

Chromium 49 packages address security issues; no more 32-bit binary plugins

March 7, 2016 / / 19 Comments

chromium_iconChromium 49 was announced on the Google Chrome Releases blog. I needed some time to compile package for my ‘ktown’ repository containing the KDE Plasma 5 environment. In fact it took more time than anticipated because I had upgraded my QEMU from 1.2.0 to 2.5.0 and that had unepected side effects: it severely affected the performance of the host server (running Slackware64 13.37 and a 2.6.37.6 kernel) and decreased the Virtual Machine speed to almost half. And when the VM froze while I was compiling chromium in it, I had enough. I reverted to QEMU 1.2.0 and all is well again.

Anyway, the new chromium 49.0.2623.75 release addresses a couple of security issues – some of these have a CVE number:

  • [$8000][560011] High CVE-2016-1630: Same-origin bypass in Blink. Credit to Mariusz Mlynski.
  • [$7500][569496] High CVE-2016-1631: Same-origin bypass in Pepper Plugin. Credit to Mariusz Mlynski.
  • [$5000][549986] High CVE-2016-1632: Bad cast in Extensions. Credit to anonymous.
  • [$3000][572537] High CVE-2016-1633: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$3000][559292] High CVE-2016-1634: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$2000][585268] High CVE-2016-1635: Use-after-free in Blink. Credit to Rob Wu.
  • [$2000][584155] High CVE-2016-1636: SRI Validation Bypass. Credit to Ryan Lester and Bryant Zadegan.
  • [$500][560291] High CVE-2015-8126: Out-of-bounds access in libpng. Credit to joerg.bornemann.
  • [$2000][555544] Medium CVE-2016-1637: Information Leak in Skia. Credit to Keve Nagy.
  • [$1000][585282] Medium CVE-2016-1638: WebAPI Bypass. Credit to Rob Wu.
  • [$1000][572224] Medium CVE-2016-1639: Use-after-free in WebRTC. Credit to Khalil Zhani.
  • [$1000][550047] Medium CVE-2016-1640: Origin confusion in Extensions UI. Credit to Luan Herrera.
  • [$500][583718] Medium CVE-2016-1641: Use-after-free in Favicon. Credit to Atte Kettunen of OUSPG.
  • [591402] CVE-2016-1642: Various fixes from internal audits, fuzzing and other initiatives.

It is advised to upgrade to this version of Chromium.

Please note that Google has stopped providing 32-bit versions of Chrome for Linux. This means that I will no longer be able to supply 32-bit plugins for Pepper Flash and for Widevine CDM support. The 32-bit plugins currently in my repository are taken from the Chrome 48 RPM and they will probably just keep functioning for a while. However I have no idea when they break, and particularly the Pepper Flash plugin will age pretty fast, considering the fact that Adobe releases security updates for Flash almost every month. YMMV.

Get my chromium packages in one of the usual locations:

The widevine and pepperflash plugin packagess for chromium can be found in the same repository.

Have fun! Eric

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑