Last week, a new LTS kernel (4.9.26), new glibc (2.25) and a new gcc compiler suite (7.1.0) landed in Slackware-current. Note that gcc no longer contains the Java compiler (gcj): subsequently Slackware’s gcc-java package has been removed from slackware-current.
We are at the head of the herd again folks. There is not yet any other distro that ships with the gcc-7 compiler by default. This will certainly pose some challenges for people who compile their stuff themselves – the SBo team warned their community about scripts that require patches to compile against gcc-7.
I have my set of challenges myself too… until now, I have not been able to compile the multilib versions of the gcc compiler suite. That’s infuriating, I can tell you. Specifically, I have issues with brig, gnat, go and objc compilers; the 7.1.0 versions of c and c++ compilers are just fine. I hope to resolve this soon-ish… until then, you will have to wait for new multilib compilers. If you really need a gcc 7.1.0 compiler (for instance, to compile a kernel module) I suggest that you (temporarily) switch to Slackware-current’s gcc 7.1.0 packages. Running your multilib system is of course not affected by this – gcc is only needed to compile stuff. I will probably release glibc-2.25_multilib packages ahead of the problematic gcc multilib packages to give you at least something.
Another interesting addition is lame. After the last Fraunhofer MP3 patent expired on 16 April 2017, the doors were opened to enable MP3 encoding support in Slackware. Several packages have been recompiled to take advantage of the new MP3 encoding capability (cdrdao, sox, ffmpeg, MPlayer, audacious-plugins) and the gstreamer packages were updated for good measure.
I have added ‘lame’ to the ‘massconvert32.sh‘ script of my compat32-tools package and updated the set of “compat32” packages in my multilib repository.
It won’t take long to see again one of the traditional threads about the ETA and/or the numbering of Slackware-next on LQ, I presume 😀
Hehe…
I assume it will be safe to say that as long as you do not see Plasma 5 added to -current, talk about a next release is not yet prudent.
Repeat this mantra continiously (until full enlightenment) if you plasma desktop user:
“Plasma is stable enough. It won’t crash.”
And no, we will not bring your plasma up if it is already down 🙂
eleksir – I assume you have never tried Plasma 5 as of late.
Good to know, I noticed lame and kernel in the changelog but completely missed the big gcc upgrade… -ENOCOFFEE
FWIW I’m a very happy Plasma 5 user, sure there’s some crash from time to time, but they’re so rare lately.
The most common is kwin sometimes crashing when under memory pressure, but it restarts itself automatically so it’s not a big deal.
But YMMV depending on your graphics stack, I’m on Intel i915 using UXA acceleration method:
$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section “Device”
Identifier “Intel Graphics”
Driver “intel”
Option “AccelMethod” “uxa”
Whoithout that snippet, the driver uses EXA, which is extremely unstable with my hardware (Intel Core i54200U, Haswell-ULT Integrated Graphics Controller)
Quite correct.
And continuing offtopic thread:
I checked out KDE4 with its plasma-on-a-desktop – well, they try to re-invent the wheel, as of early releases of KDE4. But when authors of this idea actually saw how users and distro-maintainers typically configure their working evironments, KDE4 team drop the original idea and try to adopt plasma back to, well, “normal desktop usage experince”…
And in last stable Slack (14.2) KDE4 looks and works well, if you will not leave it for a long time (say, 1+ month uptime). And it notable memory hog during its normal usage cycle 🙂 KDE3 has less appetite in this case.
Speaking about resource leaks, you can leave Xfce (gtk-2) for more than 4 months and it will no leak whole memory on desktop.
And as i talking about DE, i have to admit, that i’m not currently use any DE. On my work and at home, i use i3-wm, and, btw, humbly hope that it will be considered for inclusion for next Slackware release 🙂 it’s very easy and good alternative for traditional WM like fluxbox, blackbox, that are already in Slackware default base.
Returning back on topic.
I use stable Slack at home, it is x86 flavour and considering to switch to x86_64 in some non-too-distant future. And very fresh gcc with multilib… looks like i’ll get some interesting amusement. And it is time for bringing up builder instance in lxc environment for clean builds.
@alien, IF the the KDE4 would be put down certainly in the near future, how about replacing it instead with LinuxPAM?
That would dramatically improve the Slackware usability, while cutting its shipped size to half. Imagine everything sent in a DVD!
Darth Vader… yawn.
Note that I am not opposed to adding PAM. Just don’t expect that I am in favour of dropping KDE.
Why doesn’t Slack current use Qt4 rather than Qt5? This is more an inconvenience than a deal breaker, but the applications like Scribus moved on to Qt5 many moons ago.
about gcj… frankly speaking, I always only install gcc and gcc-c++ … all the rest I’ve always found it just a waste of disk space and internet traffic when updating… O:-)
Hello,
I’ve been working on building gcc/glibc multilib from scratch (using native slackware64 gcc/glibc) using your SlackBuild for several days. And about gcc ADA/GNAT, I’m able to build ADA by removing –host option from configure. But I still don’t know what is the effect from removing it from the compiler. But at least I can install the gcc multilib suite.
Forgot to mention, I also using guide from here to build ADA support: http://www.linuxfromscratch.org/blfs/view/svn/general/gcc-ada.html
So yes, I’m installing and using temporary gnat binary from the guide to build ADA lang support in gcc.
Hi Widya,
In the meantime I have been able to compile the gcc 7.1.0_multilib packages and uploaded them to my repository.
The issue I had was two-fold. At least, there were two important things that stopped the errors.
One is to define PKG_CONFIG_PATH. The other was to create a “compat32” version of Slackware’s “gc” package and install that on my system.
With those two changes (compared to older gcc release builds) I was able to compile 7.1.0 compilers using the old gcc 5.4.0 compilers and glibc-2.25_multilib.
I did not have a need for a private version of “isl”.
The ADA compiler (gnat) does indeed require a (temporary) existing ada compiler to be present. That is a chicken & egg problem.
John Culleton; Slackware-current DOES use Qt4.
The Qt5 is something you can add, for instance when you install my Plasma 5 desktop.
There is currently no program in Slackware that requires Qt5. Therefore, it will probably get added as an official Slackware package, the moment some program in Slackware starts requiring Qt5.
Today I updated my slackware64(multilib)-current and it’s really great to see gcc 7.1 here. Many, many thanks, Eric, for all your hard work that made this possible!