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

8 thoughts on “Multilib updates: gcc and glibc for slackware-current

  1. 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



  2. Nice !

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

    Thanks again Eric

    — kjh


  3. Pingback: Links 14/8/2016: ‘Goodbye Windows – Hello Ubuntu’, Linux Mint 18 Xfce Overview | Techrights

  4. 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?


  5. 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.


  6. 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…


  7. 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).


Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.