Ever since the birth of 64-bit Slackware in 2009, I have been maintaining a multilib repository. Today, 15 years later, things are changing!
You may know it or not, depending on your age, but I have created 64-bit Slackware from scratch late 2008 and early 2009 as a project to deal with an inguinal hernia which was really painful, and the subsequent surgery caused me to be stuck to a bed for a while. I re-wrote the SlackBuild for every package in Slackware, and created SlackBuild scripts for a whole lot of other packages that had nothing more than a ‘build’ script. I also wrote all scripts in such a way that they were capable of building 32-bit and 64-bit Slackware from the same source. Pat would not have accepted the burden of having to maintain two trees instead of one.
Not everybody needs a multilib setup, but historically there has been a need, particularly to be able to run old proprietary programs that were available only as 32-bit binaries. And then there’s the whole Microsoft Windows ecosystem of 32-bit commercial programs and games, to be run in emulators such as Wine and a platform like Steam.
I had setup the 64-bit Slackware to be “multilib-ready”. It was a pure 64-bit system but by swapping a few packages (glibc and gcc) and adding a 32-bit compatibility layer, the 64-bit Slackware would be able to run and compile 32-bit binaries. That process has always been reversible too.
Pat was clear about his own goals: he wanted the new platform to be a pure 64-bit Slackware when he was going to publish it. I had no problem with that, and thus alien’s multilib repository was born.
As said, this worked extremely well for the past 15 years. Pat would give me a heads-up whenever he was planning an upgrade to either the gcc or glibc packages, so that I would have time to prepare my own multilib versions and could release those on the heels of the official Slackware update.
Lately, Pat and me discussed our multilib collaboration occasionally and I saw his opinion shift bit-wise 🙂
Today, Pat has pushed an update to Slackware-current which effectively merges my multlib versions of gcc and glibc SlackBuild scripts with the official distro versions. This means that my own gcc and glibc multilib packages are obsolete, and I have removed them from the ‘current’ directory of the multilib repository.
In 64-bit Slackware-current you finally have multilib-capable gcc and glibc packages! All you need to add to Slackware64 now is my collection of ‘compat32’ packages. And if you want, use the massconvert32.sh script in my compat32-tools package to create these ‘compat32’ packages yourself. It does not involve any compilation – all that happens is that some official Slackware 32-bit packages are downloaded, cleaned-up a bit and then re-packaged into ‘-compat32’ versions.
Thanks Pat!
Thanks for your continued service to our community, Eric!
Wow, this is big news! Thanks for all your work Eric and Pat!
Your efforts are appreciated. Installing the multilib packages is the first thing I do on a fresh install (It’s Slackware, so that’s quite a rare event) There are a few left over static binaries that I like and still use. I keep things simple, with fluxbox, and only the things I need and use daily.
Fantastic stuff Eric and Pat and great to see things come full circle, from my group of friends I know they still play 32bit games via steam. Looks like ill be doing few remote logins to set things up with new merged packages.
Very very cool on the work on 64bit Slackware, I used 32bit on 3 systems at home and Slamd64 on my first 64bit machine which was okay. I was ecstatic the day 64bit Slackware was released downloading on my 10mb connection. Watching the data arrive mb by mb and then burning and vamoose I was off dd partitions then Slackware setup/install the media was still warm.
Then realized a couple days later eek no quake3 arena wfa and this 64bit machine has the shiny new AGP Geforce card with 512mb vram in it ahhh! Eric to the rescue with multilib packages took me a couple tries to get things right then yipee back to Quake3 Arena WFA.
Happy memories
Although I do not have use for a multilib install these days, I reckon your work on providing a fully functional 32bit env to Slackare was instrumental. Congratulations for the continuous collaboration between you and Pat. All Slackware users are in great debt on both of you!
Awesome, thanks for everything over the years! Hopefully this hardens multilib support against the inevitable time when slackware-32 stops, too.
If the 32-bit Slackware distro would be abandoned, there will be no more ‘compat32’ pacakages either. That limits the usefulness of multilib severely.
Hopefully by then we won’t need it… Or we’ll have to worry about supporting 64-bit programs with 128-bit being standard. 😉
Another benefit? Seems like every time the European Union goes on vacation in August, there’s invariably a glibc update. 🙂
I don’t understand. Or maybe the humor part of my brain is not yet awake. 🙂
Explain. please?
It seems like Pat always updates glibc when it seems like all of Europe is on vacation, so the multilib glibc is late by a week or so. (In other words, Alien Bob doesn’t have to worry about that now.)
Interesting timing. Just after wine 9, which eliminate the need of 32 bit almost completely. Before multilib was very useful, thanks Alien Bob!
Thanks to both Eric and the father of Slackware Pat.
🙂
Quite unexpected 😀
Thanks for all the time and efforts spent!
Good news !
Thanks for all you do Eric !!
— kjh
This is a bit of a pleasent surprise! I’ve been using your multilib packages for well over a decade now. I appreciate all your hard work. Thank you so very much.
Gentlemen great job. May the power be with you.
Thanks Eric for your great effort and constant work.
I have a question, with this update to Slackware-current, if i download the latest Live Edition of Slackware, will it no longer be necessary to add the “0050-multilib-current-x86_64.sxz” file from your modules folder called bonus? I ask because the file currently takes up 836M and I’m not sure if all the content is already included in Slackware-current.
If the above is correct, then to create the Wine module, the only thing that would be needed would be your Wine slackbuild from your repository and I would be able to run Windows applications?
Finally one last concern, if I want to create an updated nvidia module, the only thing I would need would be the “nvidia-driver” and “nvidia-kernel” slackbuilds from the slackbuilds.org page and that would be all?
I would greatly appreciate any guidance on this matter as I really want to learn and understand more about this great Linux distribution.
Indeed as you suspect, the liveslak module for multilib (0050-multilib-current-x86_64.sxz) does not need the gcc and glibc packages any longer because that module is meant for a Slackware-current based Live ISO, and Slackware-current itself contains a multilib-capable gcc and glibc as of now.
I will generate a batch of new ISO images and will refresh that multilib module as well.
Thank you Eric for your quick response confirming my suspicions about the module in question.
I’ll be eagerly awaiting the batch you’re going to generate of the new ISO images and the update of the multilib module. I was wondering if it would be possible, if at the time you perform this procedure, you could also update the Nvidia driver module and the Wine module. Thank you very much in advance for dedicating part of your time and your knowledge in sharing with us these fantastic contributions to this great distro.
Hi Eric, thank you very much for updating the multilib, nvidia and wine modules, in addition to this I realize that you also updated the different versions of Slackware (xfce, mate, lean, current, etc.), what a great job.
Now I have a question and I would really appreciate if you could help me better understand this concern, and it is the following, currently you have 2 files “slackware64-live-current.iso”, the first one is in the main folder, it occupies 5.2G and it was created when the Slackware changelog was updated on this date (Fri Aug 30 19:56:06 UTC 2024). And the second file is in the “slackware64-current-live” folder, it occupies 4.6G and as I understand it is created automatically every time an update is made in the Slackware changelog, in fact this Iso was created from the changelog (Tue Sep 3 21:07:09 UTC 2024).
So the question is, what is the difference between these 2 ISOs, apart from the fact that one is more updated than the other obviously, there is a difference of approximately 600M between the two, so where is this extra content and what does it correspond to? Excuse me if I am a bit annoying with this subject, but I am really curious to know this kind of things, thanks for your attention.
When preparing to answer, I noticed that I uploaded all Live ISO files in the wrong directory. They needed to one level deeper (into the ‘latest’ directory) and that’s where I now moved them.
The answer to your question: they are the same ISOs internally, but the ones that i create manually (those found in https://slackware.nl/slackware-live/latest/) use ‘zstd’ compression whereas the ISOs that are created unattended (automatically after a Slackware ChangeLog update) are compressed using ‘xz’.
You see how much better ‘xz’ compression is, but it comes with a price. The ‘zstd’ compressed ISO images boot faster than the ‘xz’ compressed ones because of the faster de-compression for ‘zstd’ archives.
When I was preparing my question, I noticed that you had changed the folder where you host all the Live ISOs, however I didn’t mention it because I thought that was what you had decided, but now I see that they are already in the correct place, latest folder.
You are right, I had forgotten that there are different types of compression, among them ‘xz’ and ‘zstd’, you mention that ‘xz’ compresses more, but on the other hand ‘zstd’ boots faster than ‘xz’, which raises the following question, in terms of performance, once the live iso starts and you log into the OS, could it be said that applications open faster when using ‘zstd’ compression instead of ‘xz’ or would the difference be almost imperceptible? In conclusion, could it be said that ‘zstd’ is better for performance reasons?
Finally, I could formally request, if possible, that you document the entire process, step by step, including all the commands you use to create the ISO ‘slackware64-live-current.iso’ which is in the latest folder, using the ‘zstd’ compression and from there, how you create the different modules located in the bonus folder (multilib, broadcom_sta, nvidia, wine, alien-current, alienrest-current), by the way, currently these last 2 modules are not in that folder, I don’t know if you plan to update them soon or if they will no longer be available.
I would really appreciate it if you could spend some time documenting this whole process in detail, since in the latest Slackware changelog, the kernel (kernel-generic-6.10.8) was updated and as far as I understand the nvidia module depends on the kernel version, which means that said module would not work in the latest ISO (slackware64-current-live Folder) and I don’t know if the other modules conflict with the latest Slackware changelogs, so it would be great to have a detailed guide to be able to update all these modules every time a conflict with the main distro changelogs arises, or simply have the option to manually update said modules. Thank you very much for your time and attention.
Thanks for all you did and will do. Much appreciated!
Eric,
Thank you for everything. You and Pat have done an amazing job over the years and this is a great accomplishment.
That’s nice!
It’s been 15yrs?
Time flies by i remember your work and slamd64 before that and that makes me feel old.
Thanks for all hard work and time you spent on this and the scripts that enables multilib and makes it easy.
Excellent – now one does not need to worry about packages not working because of an incompatible glibc after an upgrade when forgetting to upgrade multilib first.
Thanks!
Great job! You hard work is really appreciated.
Congrats Slackware! … for including Eric´s contribution.
Impressive history of contributions to Slackware. Thanks Eric for all that.
In time of elections… You are Pat’s Vicepresident!. 🙂
Regards, Francisco.
Great!
So, what was the reason for the merge all of a sudden?
For you it may seem as all of a sudden, but to me it is different. We discuss all kinds of things all the time, and multilib is only one of those many topics.
Similar to Pat putting new rust and llvm compilers in the ‘testing’ section of Slackware 15.0 so that I could again build 32-bit Chromium packages. A result of another internal discussion and I am just grateful that Pat seems to like me and does these things to help me.
Well of course to me, being a casual user, it will seem “sudden”. Also I have no doubt that you have internal discussions.
I asked, because Slackware64 appeared in 2008. At that time, many users really needed multilib for some programs and these GLIBC and GCC would’ve made things tiny bit easier back then. Now, 15 years later, when most people do not need any 32bit programs at all, these get added. Just seems strange.
If you want to complain, complain to the management. I am not telling Pat how to run his business.
I am not complaining about anything, as I do think that’s the way to go with gcc and co. If I got it right from your first answer, Pat wanted to make things easier for you by adding the multilib-capable ones to the “official” distro, so here we are.
Fair enough.