New multilib gcc and glibc packages for slackware-current

Patrick Volkerding has been busy again. See the Slackware ChangeLog.txt for a series of big updates!

There’s a new kernel. Slackware tries to stick to the 2.6.35.xx “long term support” kernels for the next release. The new kernel along with updated mesa and xf86-video-ati packages should make the owners of Ati graphics hardware happy. And my Lenovo T400 laptop with its Intel graphics feels better using this version of mesa too (no freezes in X.Org anymore). Other updates in today’s batch are primarily security fixes (quite alot actually), and fixes for software bugs.

The real reason for this post is of course the fact that there were updates to glibc and gcc. As you know, people running a multilib 64-bit Slackware-current need to install multilib versions of glibc and gcc or they lose the ability to run and compile 32-bit programs. I have new multilib versions of glibc (2.13) and gcc (rebuilt 4.5.2) packages for you.

Check out http://slackware.com/~alien/multilib/current/ if you want to download these packages.

You will also find a subdirectory “slackware64-compat32“. That directory contains all packages that are generated by the massconvert32.sh script. In other words, everything you need (along with my gcc/glibc and compat32-tools packages) to turn your Slackware64-current into a multilib system. The choice is yours: either you download and install/upgrade the packages in the “slackware-compat32” directory which I converted for you, or you run the “massconvert32.sh” script to convert these packages from the Slackware originals and install those.

If you are new to this, and want to know what the difference is between 64-bit Slackware and a multilib system, I have written detailed installation/upgrade instructions in a Wiki article at http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib .

Good luck! Eric

14 thoughts on “New multilib gcc and glibc packages for slackware-current

  1. Thanks Eric, I guess the new slack version will come with KDE 4.5.5, gcc 4.5.2, Xorg 1.9.4 and kernel 2.6.35.xx as you said. But I prefer kernel 2.6.36.xx because new webcam drivers for gspca has been integrated to kernel 2.6.36.xx series.



  2. Hi Eric!
    It’s not related to glibc packages, but exiv5 upgrade in current broke a lil thing with KDE 4.6 plasma components.
    The plasma_applet_frame.so is no longer finding libexiv2.so.5 and picture frame applets no longer work.
    I guess a small recompile is needed.






  3. Yeah. New update is great, but broke kdegraphics deps because after update delete libexiv2.so.5.
    And with 2.6.35.11 kernel AMD Catalyst don’t work properly.


  4. Yes, in fact a lot more than just kdegraphics has to be rebuilt thanks to the update of libexiv2, boost, perl etc…
    I am currently rebuilding my 4.6.0 packages for kdegraphics, kdeartwork, kdebindings, kdeplasma-addons and kdebase-runtime.
    Pat Volkerding is going to do something similar for at least kdebindings-4.5.5 in slackware-current.


  5. Hello,

    Thank you for these packages.

    I had some problems compiling the proprietary Nvidia drivers, after installing the new kernel 2.6.35.11 and using this new gcc.
    I got the message :
    “Could not compile gcc-version-check.c'”
    And it was impossible to compile the driver.
    I reinstalled the previous version of gcc-multilib, and everything worked well.

    However I did not try with the new gcc in slackware-current, so I don’t know if this comes from the new multilib gcc.


  6. Hi toto

    I just upgraded my desktop (Nvidia GeForce 6800LE) to slackware64-current and compiled Nvidia’s binary driver without any issues.
    I used the version 260.19.36: this is the file “NVIDIA-Linux-x86_64-260.19.36.run” .

    Eric


  7. I have found the problem :

    cc1 is not working : ldd cc1 said

    linux-vdso.so.1 => (0x00007fff62db0000)
    libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007fa893690000)
    libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007fa89343e000)
    libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007fa8931d1000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fa892fcd000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00007fa892db7000)
    libelf.so.0 => /usr/lib64/libelf.so.0 (0x00007fa892ba0000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fa8927fa000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa8938a3000)
    libmpfr.so.1 => not found

    In fact, I have libmpfr.so.4, but no libmpfr.so.1

    Then I made a link in /usr/lib64

    ln -s libmpfr.so.4 libmpfr.so.1

    Then ldd cc1 gives

    linux-vdso.so.1 => (0x00007fff62db0000)
    libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007fa893690000)
    libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007fa89343e000)
    libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007fa8931d1000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fa892fcd000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00007fa892db7000)
    libelf.so.0 => /usr/lib64/libelf.so.0 (0x00007fa892ba0000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fa8927fa000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa8938a3000)

    libmpfr.so.1 disapeared !!

    And compilation of gcc-version.check.c works.
    Very strange….



  8. Multi-Lib.SlackBuild would be nice. One that net-downloaded the necessary components or checked a local path entry.

    2.6.35 lacks the recent work to fix some scheduling issues. 2.6.38 is getting a lot of news.


Leave a Reply to Spirrt0 Cancel reply

Your email address will not be published.

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