## 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 … )

## Update to Computer Phosphene Last Night

Yesterday evening, a major software update was received to the computer which I name ‘Phosphene’, putting its Debian version to 9.9 from 9.8. One of the main features of the update was, an update to the NVIDIA graphics drivers, as installed from the standard Debian repositories, to version 390.116.

This allows the maximum OpenGL version supported by the drivers to be 4.6.0, and for the first time, I’m noticing that my hardware now limits me to OpenGL 4.5 .

The new driver version does not come with an update to the CUDA version, the latter of which merits some comment. When users install CUDA to Debian / Stretch from the repositories, they obtain run-time version 8.0.44, even though the newly-updated drivers support CUDA all the way up to version 9. This is a shame because CUDA 8.0 cannot be linked to, when compiling code on the GCC / CPP / C++ 6 framework, that is also standard for Debian Stretch. When we want code to run on the GPGPU, we can just load the code onto the GPU using the CUDA run-time v8.0.44, and it runs fine. But if we want to compile major software against the headers, we are locked out. The current Compiler version is too high, for this older CUDA Run-Time version. (:1) (:4)

But on the other side of this irony, I just performed an extension of my own by installing ‘ArrayFire‘ v3.6.3 , coincidentally directly after this update. And my first attempt to do so involved the binary installer that ships with its own CUDA run-time libraries, those being of version 10. Guess what, Driver version 390 is still not high enough to accommodate Run-Time version 10. This resulted in a confusing error message at first, stating that the driver was not high enough, apparently to accommodate the run-time installed system-wide, which would have been bad news for me, as it would have meant a deeply misconfigured setup – and a newly-botched update. It was only after learning that the binary installer for ArrayFire ships with its own CUDA run-time, that I was relieved to know that the system-installed run-time, was fine…

(Updated 4/29/2019, 20h20 … )

## Latte-Dock 0.6.0 Tested

One of the facts about Linux that may not be very popular with some computing enthusiasts is that the mainstream Desktop Managers – ‘KDE’, ‘Plasma’, ‘Unity’, ‘GNOME’, ‘LXDE’, etc., are different from each other, are sometimes similar to a Windows-layout – especially KDE / Plasma – but are not very similar to a MacIntosh, OS/X layout. Yet, efforts have existed to create OS/X -like desktop managers for Linux, and one of the more recent projects is “Latte-Dock“.

What makes Latte-Dock different from otherwise similar projects such as “Cairo-Dock”, is that Latte-Dock assumes that we have Plasma installed, which must be of at least version 5.8, and does not conflict with the fact that we do. And the fact that my Debian / Stretch computer, which I name ‘Phosphene’, is not even a Ubuntu computer, did not prevent me from installing Latte-Dock 0.6.0. Latte-Dock does not start unless the user starts it, and the way I go about testing such software is, that I create additional users on the computer in question, as if I was going to allow a guest to share my computer, so that in the user-space of the additional accounts, personal settings can activate Latte-Dock.

One of the ways in which Debian, Plasma 5 -based computers are strong, is in allowing the user to create more than one graphical log-in, to more than one virtual session, between which we can switch by clicking <Ctrl>+<Alt>+<F8>, or, back to the first virtual session, with <Ctrl>+<Alt>+<F7>… So my auxiliary user-identity is installed with this desktop manager, that’s designed to be similar to OS/X, at least in its appearance.

I think that this is nice software, with two major flaws:

1. On ‘Phosphene’, if I select the settings either to Preview Windows (of open applications, as the mouse passes over the dock-icons), or to Highlight those windows, these settings cause the Dock to die. This is not tragic, because when running Latte-Dock, we still have at least one Plasma-Panel active, along the top of the screen, from which we can still choose applications to run, or from which we can drag application-icons to the Dock. (:1)  This means that when the Dock has in fact crashed, I can simply have a Favourite Application -icon ready, to restart it. But the down-side with this could be, that it makes the application look bad, when in fact the culprit just seems to be, the fact that my graphics card is not strong enough to display these previewed or highlighted windows. And Latte-Dock is extremely GPU-intensive.
2. With Plasma 5.8 as the limiting factor, there appears to be no way to get a Global Application Menu working. Such applets do exist as software-projects for higher versions of Plasma than 5.8, but it cannot seem to be achieved for version 5.8 . So the OS/X experience is not 100% complete.

But if I respect these two limitations, that may not even be the fault of the Devs, I find this to be an interesting and stable piece of software.

(Updated 3/27/2019, 21h35 … )

## OpenShot-Qt Now Cooperates With Wayland Compositing.

One of the subjects which I blogged about before was, that the Debian version of OpenShot at the time, would simply freeze with desktop compositing on. That was the default, GTK version of OpenShot. Further, I can’t vouch for OpenShot under Windows because I think that the way it installs itself is botched. Yet, I am always keen to have such non-linear, 2D video editing applications available.

Well in the present, I have an up-to-date version of OpenShot installed, which is explicitly the Qt-version, installed as the package ‘openshot-qt’ on a Debian / Stretch computer. The main reason fw I have this version working, is the fact that I subscribed the computer I name ‘Phosphene’ to the Debian Multimedia Repository. Without access to this repository, Linux users can sometimes be hosed. In other cases, having its libraries installed can break dependencies with other software.

But this latest Debian Repository version of OpenShot-Qt (2.3.4), for Debian / Stretch, impresses me. Actually, when we first install it, the run-time won’t run, because of a missing library, that being ‘urllib’. This is due to the application package failing to state a dependency. This dependency can be resolved by installing ‘python-requests’ and ‘python3-requests’, which I believe also pulls in ‘python-urllib3′ and ‘python3-urllib3′. After this has been installed, ‘OpenShot-Qt’ runs.

When the developers upgraded their main build of OpenShot to version 2 (+), they needed to rewrite the source code for all the effects of the editor. And for this reason, the up-to-date version only seems to have 7 actual effects, that run over the duration that they’re applied for:

Such Effects can be applied to a clip, by dragging them onto the clip.

In contrast, because of the flexible way in which this editor defines Transitions – as grey-scale images, it still seems to have an almost unlimited supply of those, that transfer the foreground from one video clip to another (not shown).

But one way in which OpenShot makes up for its small library of 2D /time effects, is by giving its user a very powerful Title Editor, which actually invokes Blender, in order to create renderings of Titles with 3D effects:

(Updated 2/27/2019, 5h50 … )