# Compatibility GCC Installed

One of the more frustrating facts about Debian / Stretch is that its maintainers have broken with tradition, by no longer providing any compatibility versions of the main compilers, GCC, CPP and C++, which provide CC and C++ -language support, useful in 90% (+) of all programming that takes place. Instead, Debian / Stretch provides GCC / CPP / C++ version 6.3 alone. What I had already written about was, that the version of the CUDA Run-Time and Toolkit available from the standard repositories, has remained v8.0.44 for the time being. This CUDA Version does not support CC or C++ version 6 because version 6 of these compilers is too high!

One way in which power-users could try to remedy this situation would be, to install some sort of compatibility version of CC / C++, even though none is offered in the standard repositories. But, when we try to custom-compile let’s say, GCC v5.3, which would already be low enough for CUDA 8.0.44 to support, we find that GCC 6.3 is just plain unable to compile GCC 5.3, no matter what.

And so another way to solve the same problem can be, to add the old Debian Jessie / Oldstable repositories to our sources list, and then just to install from there.

I find this to be an extremely bad idea.

First of all, Debian differs from Ubuntu, in that Debian never provided GCC 5.3. In Debian / Jessie, what we got was GCC 4.8, or maybe even v4.9. But more importantly, simply sandwiching two incompatible repositories together can create a fatal set of problems.

What I was finally able to do, was just to download roughly a dozen packages as binaries, from the Debian Repository Web-site, which finally provided GCC, CPP and C++ v4.8. The path I took required that I run into the error message numerous times that dependencies could not be satisfied, because under Debian, neither ‘/usr/bin/gcc’ nor ‘/usr/bin/c++’ are provided by a single, binary package. Each is provided by packages, that depend uniquely on other packages, that are also not in the repositories.

Further, once the power-user has in fact installed binaries, after making sure that none of their file-names overlap, he must also create a system of Debian Alternatives, that allow him to switch between compilers easily. The problem with that is the fact that because, under Debian / Stretch, no provision was ever made by Package Maintainers for alternatives to exist, automatic mechanisms have also not been provided, to install ‘Link Groups’. The Link Groups ‘cc’, ‘cpp’ and ‘c++’ exist, but only in such a way as to provide one executable each.

As I was doing my best to install the Link Groups, I made a mistake, which simply over-wrote ‘/usr/bin/gcc’ with a different symlink, and which therefore forced me to (1) delete the link-group, and (2) reinstall GCC 6.3 from the package manager. After that, a new attempt to set up the link-groups succeeded:


dirk@Phosphene:~$su Password: root@Phosphene:/home/dirk# update-alternatives --config cc There are 2 choices for the alternative cc (providing /usr/bin/cc). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/gcc-6 20 auto mode 1 /usr/bin/gcc-4.8 10 manual mode 2 /usr/bin/gcc-6 20 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config cpp There are 2 choices for the alternative cpp (providing /usr/bin/cpp). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/cpp-6 20 auto mode 1 /usr/bin/cpp-4.8 10 manual mode 2 /usr/bin/cpp-6 20 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# update-alternatives --config c++ There are 2 choices for the alternative c++ (providing /usr/bin/c++). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/g++-6 20 auto mode 1 /usr/bin/g++-4.8 10 manual mode 2 /usr/bin/g++-6 20 manual mode Press to keep the current choice[*], or type selection number: root@Phosphene:/home/dirk# exit exit dirk@Phosphene:~$



Note: The first link above, named ‘cc’, has a corresponding slave-link named ‘gcc’, thereby forming the only real ‘Link Group’. The others are just plain Links.

I am reasonably certain that none of these link-groups are broken. But what my reader should be able to infer from what I’ve written, is that It would be a hare-brained attempt, to duplicate what I’ve done, entirely based on this blog posting.

(Edit 5/03/2019, 11h45 : )

Just to prove how hare-brained this idea really is, I just uninstalled the alternative compilers, and replaced them with the GCC / CPP / C++ tool-chain, version 4.9, and made that part of the update-alternatives system as above! (:3)

(End of Edit.)

So what does this provide me with (hopefully)?

(Updated 5/02/2019, 12h15 … )

(As of 4/30/2019 : )

I should be able to custom-compile medium or even large projects, that depend on CUDA 8, in the future.

However, I should make no attempt to recompile ‘ArrayFire’ now, using GCC 4.8, because that may well be a project so advanced, that by its nature, it may require GCC 5 or even GCC 6. And such is well because the binary installer for ArrayFire already shipped with CUDA Runt-Time v10. So, using the binaries directly from NVIDIA, the ArrayFire devs were able to compile that. And using older compilers Debian Maintainers were able to compile smaller packages, that provide computing back-ends for application-packages, but that link to CUDA 8. (:2)

The version of ArrayFire that I presently have works fine, because in addition to providing a CPU-version for each Demo, ArrayFire as compiled on my machine provides a working, OpenCL-version for each Demo.

However, that part of ArrayFire that allows for graphics-output to be integrated with OpenCL computing, which is called ‘Forge’, cannot be configured without any linkage to CUDA, i.e., in a way that solely depends on OpenCL. The best I was able to do with Forge was, to disable building its CUDA-Examples. Yet, I see that Forge did link to my installed OpenCL libraries as well. What this means is that, when I run ArrayFire Demos of graphics output, the CUDA versions are never verified, and some sort of performance bottleneck may also take place because the ArrayFire Demo is based on OpenCL, while Forge depends heavily on links to CUDA. (:1)

But as it stands, I have not discovered any ArrayFire Demos yet, that just don’t work.

1:)

It just so happens that ‘Forge’ also links to the installed OpenGL version. But this fact may be irrelevant because, while CUDA may have an inherent ability to pass graphics output to OpenGL, it may happen that OpenCL v1.1 just doesn’t. And so a CPU-core may still be in the loop, in this exercise.

The result would be that Forge provides an API for graphics output, but just not in a way that only depends on the GPU. Yet, OpenCL Demos were provided by the binary version of ArrayFire as well, that provided graphics output using Forge. So somewhere, the combination was already meant to work.

2:)

I can now confirm, that ‘ArrayFire 3.7.0′ requires GCC / CPP / C++ higher than version 4.8 to compile. When I tried my latest compatibility arrangement, initially, the build process continued correctly. But eventually, in a CPU-back-end that doesn’t even have anything to do with CUDA, a complicated C++ expression was encountered, which compiler version 4.8 could not parse. And this was in the middle of source code, well beyond anything that CUDA can be expected to run, in terms of complexity. The following is the error-code that I obtain:


[  0%] Building CXX object src/backend/cpu/CMakeFiles/afcpu.dir/Array.cpp.o
In file included from /home/dirk/Programs/arrayfire/src/backend/cpu/Array.cpp:16:0:
/home/dirk/Programs/arrayfire/src/backend/common/jit/NodeIterator.hpp: In instantiation of ‘class common::NodeIterator’:
/home/dirk/Programs/arrayfire/src/backend/cpu/Array.cpp:237:41:   required from ‘cpu::Array cpu::createNodeArray(const af::dim4&, cpu::jit::Node_ptr) [with T = float; cpu::jit::Node_ptr = std::shared_ptr]’
/home/dirk/Programs/arrayfire/src/backend/cpu/Array.cpp:344:1:   required from here
/home/dirk/Programs/arrayfire/src/backend/common/jit/NodeIterator.hpp:99:19: error: function ‘common::NodeIterator& common::NodeIterator::operator=(common::NodeIterator&&) [with Node = cpu::jit::Node]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘common::NodeIterator& common::NodeIterator::operator=(common::NodeIterator&&)’
NodeIterator& operator=(NodeIterator&& other) noexcept = default;
^
/home/dirk/Programs/arrayfire/src/backend/cpu/Array.cpp:241: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccEW7AQz.out file, please attach this to your bugreport.
src/backend/cpu/CMakeFiles/afcpu.dir/build.make:62: recipe for target 'src/backend/cpu/CMakeFiles/afcpu.dir/Array.cpp.o' failed
make[2]: *** [src/backend/cpu/CMakeFiles/afcpu.dir/Array.cpp.o] Error 1
CMakeFiles/Makefile2:1419: recipe for target 'src/backend/cpu/CMakeFiles/afcpu.dir/all' failed
make[1]: *** [src/backend/cpu/CMakeFiles/afcpu.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2



Yet, I was able to set all my Alternatives back to the default versions of 6.3, and then just to rebuild ArrayFire without CUDA support, as before. Further, ArrayFire 3.6.3 does exactly the same thing. The file which the error message recommends we attach, when filing bug reports, can be found at this link:

http://dirkmittler.homeip.net/text/ccEW7AQz.out.txt

I can also observe that, If the user has given the commands:


$make -j 4 ( ... )$ su
( ... )
# make install



Then what will follow is, that any subsequent attempts to run ‘make’ again as user will fail, because the ‘make install’ target wrote to files in the build directory tree in such a way, that as user, ‘make’ cannot write to them again. I needed to Trash my whole build folder, before being able to reconfigure, and then rebuild ArrayFire.

(Update 5/02/2019, 12h15 : )

3:)

This exercise has drawn my attention to a fact, which I was previously not conscious of, concerning which compilers would usually be installed on a Debian / Jessie system.

Strictly according to Debian repositories, this would be GCC / CPP / G++ v4.8.4. But according to the Debian Security repository, it would be v4.9.2.

This could affect how easily my readers might be able, or might not be able to compile the source-code I have offered in another posting. Because all my computers have the security repository in their sources list by default, my older Debian / Jessie computers naturally have GCC v4.9.2 installed. When I observe that those computers are equally capable of compiling my source code, I may not be taking into account, that readers with Debian / Jessie computers, who are not subscribed to the security repositories, may still not be able to compile that code.

I apologize to any readers who may have run in to this. But the fact remains that because that code was designed to handle complex numbers in a straightforward way, any compiler version that doesn’t support complex numbers, will fail to compile it.

Dirk