ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!

A project which has fixated me for several days has been, to get the API which is named “ArrayFire” custom-compiled, specifically version 3.5.1 of that API, to enable CUDA support. This poses a special problem because when we use the Debian / Stretch repositories to install the CUDA Run-Time, we are limited to installing version 8.0.44. This run-time is too old, to be compatible with the standard GCC / CPP / C++ compiler-set available under the same distribution of Linux. Therefore, it can be hard for users and Debian Maintainers alike to build projects that use CUDA, and which are compatible with -Stretch.

Why use ArrayFire? Because writing kernels for parallel computing on the GPU is hard. ArrayFire is supposed to make the idea more-accessible to people like me, who have no specific training in writing highly parallel code.

When we install ArrayFire from the repositories, OpenCL support is provided, but not CUDA support.

I’ve hatched a plan by which I can install an alternative compiler set on the computer I name ‘Phosphene’, that being GCC / CPP / C++ version 4.9.2, and with which I can switch my compilers to that version, so that maybe, I can compile projects in the future, that do use CUDA, and that are sophisticated enough to require a full compiler-suite to build.

What I’ve found was that contrarily to how it went the previous time, this time I’ve scored a success. :-)  Not only did the project compile without errors, but then, a specific Demo that ships with the source-code version, that uses the ability of CUDA to pass graphics to the OpenGL rendering of the GPU, also ran without errors…


So now I can be sure that the tool-chain which I’ve installed, is up to the task of compiling highly-complex CUDA projects.

(Update 5/03/2019, 7h30 : )

Continue reading ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!

ArrayFire 3.5.1 Compiled, using GCC 4.8.4 and CUDA – Failure!

In this earlier posting I had written, that I had installed GCC / CPP / C++ 4.8.4, alongside versions 6.3, on my computer named ‘Phosphene’, even though Debian / Stretch computers are not meant by design, to offer earlier versions of those compilers. And I had done so, specifically so that I’d be able to compile CUDA 8 projects, for which GCC version 6 is too high.

One possible CUDA project would have been ArrayFire 3.7.0, or version 3.6.3 of that same library. However, what I found was that these latest versions of ArrayFire require a stronger compiler, than v4.8.

Well what I have now been able to do is, to compile ArrayFire 3.5.1 using the GCC 4.8.4 tool-chain, and to do so, even with CUDA support. This is higher than what Debian Maintainers could do, if only because the package-repository version of ArrayFire do not include CUDA back-ends, only OpenCL back-ends.

This proves that my GCC 4.8.4, compatibility tool-chain is correctly installed.

The question which I must now ponder is, whether I should next install v3.5.1 of ArrayFire to my root file-system, replacing v3.7.0, just because the lower version gives me CUDA support. I might not because v3.7.0 already gives me OpenCL support. Either way, I built v3.5.1 with the configuration option, to ‘Use System Forge’, which may mean that I won’t need to recompile Forge, which was compiled as version 1.0.4, and as belonging to ArrayFire 3.7.0.

Installing v3.5.1 to my root file-system would be a necessary step, to verify whether the Demos actually run, since all ArrayFire Demos need to be linked to the same library-versions that their ArrayFire build generated.


What I have found is twofold:

  1. The Configuration option ‘Use System Forge’ will not work, when the installed version of Forge is 1.0.4. This needs to be unchecked, and the integrated version of Forge built, and installed, and
  2. Even though the exercise compiled, it will not run.

When trying to run a CUDA executable, I get the error message:


terminate called after throwing an instance of 'std::regex_error'
  what():  regex_error


What this result means is that I have not been able to confirm that compiling and linking projects to CUDA finally works, using the platform I’ve created, even though the actual compilation produces no error message.