Alien Pastures

My thoughts on Slackware, life and everything

Tag: gcc (Page 2 of 5)

Chromium is now compiled using clang

October 30, 2017 / / 10 Comments

chromium_iconIn 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:

Have fun! Eric

What if gcc 7 gives you headaches?

June 25, 2017 / / 10 Comments

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 result is a gcc5-5.4.0 package – for Slackware-current, both 32bit and 64bit. Get them at http://www.slackware.com/~alien/slackbuilds/gcc5/ .

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

source /etc/profile.d/gcc5.sh

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:

export CC=gcc-5
export CPP=cpp-5
export CXX=g++-5
export AR=gcc-ar-5
export NM=gcc-nm-5
export RANLIB=gcc-ranlib-5

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)

Hope this helps some people!

Eric

Some thoughts on the recent updates in Slackware-current

May 7, 2017 / / 18 Comments

 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.

Rebuilt multilib gcc compiler suite for slackware-current

August 8, 2015 / / 4 Comments

There were many updates for Slackware-current last night. One of them was a rebuilt gcc compiler suite, and therefore an updated multilib compiler set was due as well.

The new multilib gcc packages are now online, The set of 32-bit “compat32” packages for slackware64-current has also been refreshed. The gcc packages had to be rebuilt because of other package updates causing library version bumps, but Pat took the opportunity to add two shell scripts “c89” and “c99” that are part of POSIX standard – they call the compiler with additional compatibility parameters. This was necessitated by the fact that recent git checkouts of the VLC mediaplayer would not compile on Slackware because the VLC developers started enforcing a check on the availability of the “c99” command.

You can obtain the updated multilib packages from the URLs below or from any other mirror near you that carries copies of my repositories:

A refresher on “multilib” for new users of Slackware: if you want to use (binary-only) 32-bit software on a 64-bit Slackware installation then that is not possible out of the box, because Slackware64 is a pure 64-bit OS. You need to expand the OS with “multilib capability” so that the OS can run (and compile) 32-bit programs as well. Examples of 32-bit (closed-source) programs are Skype, Valve’s Steam Client, the WINE emulator, the Pipelight browser plugin, Citrix client etc.

Instructions on how to add or update multilib on your 64-bit Slackware can be found on the Slackware Documentation Project. Also, the slackpkg+ extension to Slackware’s own slackpkg contains the script “setupmultilib.sh” which can help you in setting up multilib properly. With slackpkg+ it is then trivial to keep your multilib installation up to date when updates occur.

Security tip:

One note on the side about last night’s Slackware -current update. The work on this update was supposed to take a while longer because Pat wants to update additional packages and a proper integration is important so that things don’t break due to library incompatibilities. But the update to the mozilla-firefox package addresses a serious and critical security issue. This security fix needed to get out to you people as fast as possible. The exploit (which was found in the wild by an attentive Firefox user and then reported to Mozilla) uses Firefox’s internal PDF viewer implementation to gain access to your local files, and uploads e.g. your ssh configuration and keys, the password file, pidgin and psi configuration files to a Russian server – pretty sensitive things.

If you have been using Firefox 38 or 39 (normal or ESR versions) on your Linux computer and visited dodgy sites recently, and you have ssh keys for accessing remote servers without a password, you may want to consider replacing these ssh keys with fresh ones.

Enjoy! Eric

Multilib gcc updated to address changes in slackware-current

April 25, 2015 / / 11 Comments

slackware_multilib

In slackware-current two inter-related packages were updated yesterday: libmpc and gcc. It turns out that the update of libmpc caused a library version change. Since the gcc compiler is dynamically linked to libmpc, the gcc packages had to be recompiled in order to make it link against the new libmpc.so.3 library. Another reason for recompiling the gcc package was the missing libiberty.a file. The gcc.SlackBuild needed an additional configuration parameter to make it install into the package again.

Unfortunately that slackware-current update broke the multilib gcc packages which I have in my own repository, as several people noticed … the quick’n’dirty fix was (cd /usr/lib64 ; ln -s libmpc.so.3 libmpc.so.2).

I have recompiled the multilib gcc twice (after applying Slackware’s updates to the gcc-multilib.SlackBuild): first compilation was done with that symlink created like I just described. That resulted in the desired linkage to the new libmpc.so.3 library. Then I removed the symlink which I had created earlier and compiled the gcc packages again, just to be sure (for Slackware, this double compilation was performed as well).

The new gcc packages are now online, along with an update to the massconvert32.sh script which is part of the compat32-tools package. Also I refreshed the set of 32-bit “compat32” packages which I create from the official 32-bit Slackware package tree, because there were several updated packages in Slackware (again), and I added the libva-intel-driver-compat32 package on request.

Here is where you can find the updated packages:

If you wonder what this multilib is all about: it is needed if you want to use (binary-only) 32-bit software on 64-bit Slackware. Examples of that are Skype, Valve’s Steam Client, the WINE emulator, the Pipelight browser plugin, Citrix client etc.

Instructions on how to add or update multilib on your 64-bit Slackware can be found on the Slackware Documentation Project. Also, the slackpkg+ extension to Slackware’s own slackpkg contains the script “setupmultilib.sh” which can help you in setting up multilib properly.

 

Enjoy! Eric

PS: The nice graphic at the top was taken from the page http://gnu-linux-slackware.blogspot.nl/2013/01/switch-to-multilib-with-32-bit.html which is a Slackware related blog by Ismail.

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑