Alien Pastures

My thoughts on Slackware, life and everything

Tag: compat32

Slackware-current has absorbed my multilib gcc and glibc packages

August 30, 2024 / / 35 Comments

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!

Multilib gcc updated to address changes in slackware-current

April 25, 2015 / / 11 Comments

slackware_multilib

In slackware-current two inter-related packages were updated yesterday: libmpc and gcc. It turns out that the update of libmpc caused a library version change. Since the gcc compiler is dynamically linked to libmpc, the gcc packages had to be recompiled in order to make it link against the newĀ libmpc.so.3 library. Another reason for recompiling the gcc package was the missing libiberty.a file. The gcc.SlackBuildĀ needed an additional configuration parameter to make it install into the package again.

Unfortunately that slackware-current update broke the multilib gcc packages which I have in my own repository, as several people noticed … the quick’n’dirty fix was (cd /usr/lib64 ; ln -s libmpc.so.3 libmpc.so.2).

I have recompiled the multilib gcc twice (after applying Slackware’s updates toĀ the gcc-multilib.SlackBuild): first compilation was done with that symlink created like I just described. That resulted in the desiredĀ linkageĀ toĀ the new libmpc.so.3 library. Then I removed the symlink which I had created earlier and compiled the gcc packages again, just to be sure (for Slackware, this double compilation was performedĀ as well).

The new gcc packages are now online, along with an update to the massconvert32.sh script which is part of the compat32-tools package. Also I refreshed the set of 32-bit “compat32” packages which I create from the official 32-bit Slackware package tree, because there were several updated packages in Slackware (again), and I added the libva-intel-driver-compat32 package on request.

Here is where you can find the updated packages:

If you wonder what thisĀ multilib is all about: it is needed if you want to use (binary-only) 32-bit software on 64-bit Slackware. Examples of that are Skype, Valveā€™s Steam Client, the WINEĀ emulator, the Pipelight browser plugin, Citrix client etc.

Instructions on how to add or update multilib on your 64-bit Slackware can be found on the Slackware Documentation Project. Also, the slackpkg+ extension to Slackware’s own slackpkg contains the script “setupmultilib.sh” which can help you in setting up multilib properly.

 

Enjoy! Eric

PS: The nice graphic at the top was taken from the pageĀ http://gnu-linux-slackware.blogspot.nl/2013/01/switch-to-multilib-with-32-bit.html which is a Slackware related blog by Ismail.

End of the week, end of the cycle?

September 21, 2012 / / 11 Comments

Most of you will have seen the latest comment in the slackware-current ChangeLog:

Wed Sep 19 23:52:16 UTC 2012
Here we go one more time with Slackware 14.0 release candidate 5.
Really, this time it is not a drill!Ā  Everything is in place and
ready to release at this point, and unless there’s some kind of
showstopper found (which doesn’t seem too likely after all the
testing that’s happened), the release can be expected soon.

It means that we could see a Slackware 14 release very soon. As always, it’s ready when it is ready… but it is not going to take weeks.

I took the opportunity to implement some ideas which I had been thinking about for my multilib packages. These are the results:

  • In the compat32-tools package, the “convertpkg-compat32” script will now by default add a “compat32” build tag to the converted package name. For instance, when the package “e2fsprogs-1.42.5-x86_64-1.txz” is converted, it becomes “e2fsprogs-compat32-1.42.5-x86_64-1compat32.txz”.
  • Also in the compat32-tools package, the “massconvert32.sh” script will now check the Slackware patches directory to see if there is an update for any package it needs to convert. For instance, when you run the script against a Slackware 13.37 package tree you would get the converted package “openssl-solibs-compat32-0.9.8x-i486-1_slack13.37compat32.txz” instead of “openssl-solibs-compat32-0.9.8r-i486-3compat32.txz” (which is part of the original 13.37 release).
  • The reason for adding a “compat32” build tag to all converted packages is to make system upgrades of a multilib Slackware easier. Up to now, if you were using slackpkg for the upgrades, you had to manually deselect all compat32 packages in the list which is produced by the command “slackpkg clean-system”. With the new scripts, you are able to blacklist all my multilib packages by just adding one line to the file “/etc/slackpkg/blacklist”:

# Blacklist all multilib ‘compat32’ packages:

[0-9]+compat32

  • During the slackware-current development cycle there were several upgrades of the gcc packages. At one time I had to fix my multilib rebuild of gcc. I want to keep my package build numbers in sync with Slackware’s original 64-bit packages to avoid confusion of the kind “do I have the correct multilib package installed“, so I decided to give the fixed gcc packages a build number of “1fix1_alien” instead of “1alien”. Unfortunately this broke the slackpkg blacklist line for my “alien” tag. The expression “[0-9]+alien” will not match packages with a “1fix1_alien” build number. So I decided to rename the multilib gcc packages and use the “1alien” build tag. This will be much friendlier for people who upgrade from Slackware 13.37 to 14.0. If you have been running -current all the time, you should be smart enough to understand my reasoning šŸ™‚

If you are currently running Slackware 13.37 and want to profit from these enhancements, you can of course upgrade to my new compat32-tools package – even though I make it avalable in the “current” (and later on “14.0“) directory of my multilib repository. I took care not to break the compatibility with Slackware 13.37 when I updated the package during the past development cycle of slackware-current.

A note about the Slackware Documentation Project

WeĀ  (the editors) are steadily working on expanding the documentation wiki. I recently added an article about how to perform a Slackware system upgrade, to help people who are running Slackware 13.37 and want to upgrade to 14.0 when that is released. Check out “Upgrade Slackware to a New Release“.

We would like to welcome your contributions as well! If you had a problem in Slackware and found the solution, or if you have some particular knowledge which your fellow Slackers could profit from, feel free to visit the Wiki’s HOWTO’s page and create your own article there. Check the existing HOWTO articles to get a feel for what is possible.

If you do not want to write a new article, we still value your feedback. If you have any comments or suggestions about improvements for the site, we would like to hear from you.

Cheers, Eric

Multilib updates to go with new kernel

March 9, 2011 / / 3 Comments

Hi folks!

Slackware -current’s kernel has been updated to 2.6.37.3 (something many of you probably did not expect) as part of the large update leading to the first release candidate for Slackware 13.37.

This newer kernel seems to work better on all the developers’ computers especially for X sessions.Also speakup (a kernel driver for speech synthesizers) is now part of the kernel since 2.6.37, which means that a separate kernel containing a speakup patch could be dropped from the installer.

Anyway, as part of the kernel update, Pat Volkerding rebuilt the glibc packages against the new kernel headers.

Those of you who run a multilib-enhanced version of Slackware64 know what that means… I have updated my own multilib repository with rebuilt glibc-2.13 packages. This is not an urgent or mandatory upgrade for you, as the previous version of the multilib glibc packages will probably work fine. But for compiling new software that wants to use the kernel api you’d want to go with the rebuilt versions.

Get the new glibc packages at http://slackware.com/~alien/multilib/current/ as usual.

As a bonus, I have also updated my massconvert32.sh script which is part of the compat32-tools package in the same directory. Several packages have been added for the benefit of compiling and running wine. Please tell me if more packages have to be added to that script!

I also updated the content of the slackware64-compat32 directory which holds a copy of all the packages which are created by running the massconvert32.sh script (to make it easier for you if you have your doubts about how to use that script).

Eric

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑