Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 417 other subscribers

My Favourites

Slackware

Calendar

February 2019
M T W T F S S
« Jan    
 123
45678910
11121314151617
18192021222324
25262728  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current

RSS SBo

Meta

Multilib updates: gcc and glibc for slackware-current

blueSW-64px
The update which was announced for slackware-current today mentioned new gcc and glibc packages alongside a new kernel. The 4.4.17 kernel should fix the issue with overlayfs which affected the Slackware Live Edition. The updated gcc-5.4.0 and glibc-2.24 packages warranted a similar update to their multilib versions.
New to multilib or don’t know what it is all about? Read the multilib article found in the Slackware Documentation Project.

So I built the packages tonight and they are accompanied by some updates to the “compat32” set for various Slackware releases. Download the new multilib packages here:

Mirror:

Have fun! Eric

Comments

Comment from kjhambrick
Posted: August 13, 2016 at 13:13

Thanks for multilib Eric !

I wouldn’t be able to run Slackware on my main Dev Box without it.

And maintaining multilib for 7 separate versions of Slackware is no small feat !

One suggestion for the multilib doc at docs.slackware.com …

Just below the Slackware64 Current Block is a header: ‘There is one additional package that you install using the “installpkg” program:’ which I almost missed, thinking it was part of the Slackware64 Block.

I wonder if there’s a way to make that stand out ?

I rerun /usr/sbin/massconvert32.sh every time I update any packages in Slackware64 which is included in the referenced compat32-tools-3.7-noarch-1alien.tgz

Those tools are REAL important 🙂

Anyhow, thanks again for all you do !

— kjh

Comment from alienbob
Posted: August 13, 2016 at 13:47

You make a good point, and I have tried to enhance the article by giving it its own section: http://docs.slackware.com/slackware:multilib#all_releases_of_slackware to make it stand out better.

Comment from kjhambrick
Posted: August 13, 2016 at 13:53

Nice !

It’s now very clear that
compat32-tools-3.7-noarch-1alien.tgz is an ‘essential ingredient’ of multilib.

Thanks again Eric

— kjh

Pingback from Links 14/8/2016: ‘Goodbye Windows – Hello Ubuntu’, Linux Mint 18 Xfce Overview | Techrights
Posted: August 14, 2016 at 13:23

[…] Multilib updates: gcc and glibc for slackware-current […]

Comment from slodki
Posted: August 14, 2016 at 21:08

Now there is a problem with /usr/include/KF5/AkonadiCore/std_exception.h after gcc upgrade in -current: it’s pointing to the old version. Should some KDE packages be recompiled with new gcc?
Maybe there is a way to skip this hard-coded (at compile time) ugly hack (for case-insensitive systems) at /usr/include/KF5/AkonadiCore/exception.h?

Comment from alienbob
Posted: August 14, 2016 at 21:36

Indeed if you want to compile sources that have an akonadi dependency you will have to recompile akonadi first on Slackware-current.
If you come up with a patch to circumvent this, I will have a look.

Comment from slodki
Posted: September 3, 2016 at 18:53

Your KF5 latest version (16.08) from current dir is not compiled on current slackware (uses old 5.3.0 gcc vs 5.4.0 in current). “latest” dir in Ktown shouldn’t be linked to 14.2 anymore…

Comment from alienbob
Posted: September 4, 2016 at 17:11

slodki, the “latest” available set for Slackware-current is indeed compiled on Slackware 14.2. I am not going to recompile it for Slackware-current until the divergence becomes too big that issues arise. It is simply too time-consuming.

I am using Plasma 5 “latest” on my -current laptop without issues. What are your issues? As far as I know, you only may need to recompile akonadi if you want to compile package depending on the Akonadi headers (/usr/include/KF5/AkonadiCore/std_exception.h to be specific).

Write a comment