The GCC compiler suite in slackware-current got a major version bump last week in a dualupdate (the second update added the new ‘gcc-gdc’ package).
GCC version went up from 8.3.0 to 9.1.0.
I just uploaded the multilib version of the GCC packages, including that ‘gcc-gdc‘ package containing the new ‘D’ compiler.
The set of ‘*compat32’ packages was also refreshed with the latest 32bit binaries from Slackware 14.2 and -current.
Grab the packages from my server or from any mirror (those will have a few hours delay until they catch up).
Today, Pat upgraded the GCC compiler suite in slackware-current to 8.3.0 and I did the same for the multilib version of the GCC packages. The release was simultaneous on both sides thanks to the fact that I had advance access to the Slackware package files. Thanks Pat.
And you’ll also enjoy a new kernel in that same batch of updates in -current.
In my previous blog post about Chromium 62, I described the issues I had while attempting to compile it on Slackware14.2. The gcc compiler suite on Slackware 14.2 is “too old” for Chromium because it lacks the required C++11 support. More to the point, the Google developers use clang instead of gcc for their own compilations and therefore gcc support is becoming stale. Response by Google developers when they encounter a gcc-related bug report is to ‘please switch to clang’.
Unfortunately, as previously noted, the chromium build framework will download Google’s own clang binaries in that case. I do not trust these binaries on my Slackware computer. I stated that I would not switch to clang until it became possible to either use Slackware’s own clang or else compile Google’s clang from source on my own computer.
I exchanged a couple of emails with Google developers and got enough hints to convince me that compiling Google’s clang was possible.
And indeed, after a week of trial and error (especially the 32bit build gave me headaches) I managed to add all the needed bits and pieces to my chromium.SlackBuild.
The updated packages for Chromium (version 62.0.3202.75) for which the sources were released last week, are compiled with clang instead of gcc, and that clang has been compiled from source first. Of course, this adds time to the package build… every time I compile the chromium package, the SlackBuild script has to download and compile clang as well. But, the process is fully automated and a separate “gcc5” package is not needed on Slackware 14.2. Also, we are future-proof now. And an added bonus is that the package size has decreased substantially, from 65 to 56 MB (a 14% decrement).
Note about the new Chromium release: it addresses CVE-2017-15396 (Stack overflow in V8) so it will be good to upgrade.
If you want to compile chromium using gcc nevertheless (to decrease the total build time for instance) then all you need to do is: set the variable “USE_CLANG” to “0”.
On Slackware 14.2 you still need my gcc5 package and apply the instructions from my previous post.
The packages for chromium are available for Slackware 14.2 and -current in my repository or one of its mirrors:
In Slackware-current we use version 7.1.0 of the gcc compiler suite. These advanced compilers can sometimes be quite a bit more strict about what they accept as valid code. As a consequence, you will regularly run into compilation issues with software. Not just the software made with the scripts on slackbuilds.org, but also some of the software in the Slackware core distribution requires patches in order to get them to compile.
Until now, I have been lucky to find the patches I needed in the repositories of other distributions, or else developers patched their software themselves. But there will be corner cases where solutions and patches are not readily found, or the developers will simply not support gcc 7. Pale Moon is such a piece of software where the developers recommend compiling with gcc 4.x or as a last resort, gcc 5.
Also, the latest gcc compiler suite has dropped their Java compiler, it was no longer developed. So, no more gcc-java package. However if you want to bootstrap the OpenJDK compiler software, you need to start with a Java compiler. The openjdk developers recommend an already built OpenJDK package to compile a new release. But there may still be a case where you have to bootstrap that very first OpenJDK compiler.
So I took the old sources for gcc-5.4.0 which was part of Slackware-current for a while (11 August 2016 to 4 May 2017), and re-worked my gcc-multilib.SlackBuild script:
I renamed the package to “gcc5” so that it can be installed alongside Slackware’s gcc 7 packages
The binaries were given a suffix “-5” to make them stand apart from Slackware’s default compilers
All except the C, C++ and Java language compilers were removed
Only one all-encompassing package is built by the script
A profile script was added – you can ‘source’ it to activate the gcc-5 compilers as preferred compilers
The 64bit package is a multilib version, but you can install it without issues on a pure 64bit system. You will just not be able to compile 32bit programs with it.
How to use these compilers?
Simple: in your console or terminal, you ‘source’ the provided profile script, like this (there’s a c-shell compatible script as well):
The command “source” is equivalent to the dot command ” . “. The profile script will (re-)define the common variables that are used by make and other programs to determine which binary to run as the compiler:
So, all you have to do next is run your compile job as usual, in that same console or terminal. Nothing else needs to be done after sourcing the profile script. Your program will be compiled with the binaries provided by the gcc5 package.
I did limited testing:
With the above instructions, I ran my palemoon.SlackBuild script and it provided a package (whereas the gcc7 compiler in Slackware-current would cause the compilation to fail)
The provided gcj (GNU Java Compiler) was able to bootstrap the OpenJDK 7 sourcecode into a working binary package, which I could then use to compile OpenJDK 8 on slackware-current (OpenJDK 7 is the last release that can still be bootstrapped with the gcj compiler)
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.