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
Ever since the birth of 64-bit Slackware in 2009, I have been maintaining a multilib repository. Today, 15 years later, things are changing!
Remember the date! On May 18th of 2020, PAM got added to the Slackware-current core. In case that makes you worry, wonder or causes you to ponder leaving Slackware behind, don’t let this change scare you. PAM has come a long way, it is safe and in Slackware, it is not getting in your way. You won’t have to change a single thing to your computer except installing three new packages (slackpkg install-new) before you reboot. Adding PAM should finally remove the self-imposed writer’s block in Patrick’s mind and open the path to long-awaited renewals in the KDE and XFCE areas.
The GCC compiler suite in slackware-current got a major version bump last week in a 
Recent comments