Gcc versions later than 7 are not supported by CUDA 10 - Qt Error in Arch Linux - qt

I am running Arch Linux and trying to build a project in Qt however, Qt spits the following error:
/opt/cuda/include/crt/host_config.h:129: error: #error -- unsupported GNU version! gcc versions later than 7 are not supported!
I have already tried a suggestion from a previous Stack Overflow post found here:
CUDA incompatible with my gcc version
I did not use the exact command as my cuda is located in /opt/cuda/bin/gcc. I did the same command for g++. However, the terminal outputs that these files are already linked. I did confirm this by going to the actual file and looking at it's properties.
Can someone please suggest a solution to my issue?

I managed to do so usung this two lines, this will update the symbolic links of cuda to gcc7
ln -s /usr/bin/gcc-7 /usr/local/cuda/bin/gcc
ln -s /usr/bin/g++-7 /usr/local/cuda/bin/g++

The issue comes from cuda-10.0/targets/x86_64-linux/include/crt/host_config.h in the main CUDA-10 directory tree. The target for your architecture was placed in /opt.
Some posts recommend faking the inequality
if __GNUC__ > 7
to say
if __GNUC__ > 8
but that is a bad idea. Using
make 'NVCCFLAGS=-m64 -D__GNUC__=7' -k
is permissible in some trivial cases, but still fundamentally the same bad hack.
You probably have alternates on your system which has constructed symbolic links pointing to the version 8 gnu tool chain files. That's why you get an indication version 7 is already installed.
You can learn how to modify your alternates for just your developer users BUT NOT for root or any system admin accounts. You may want to remember how to switch back and forth between 7 and 8 so you only use 7 when actually needed, since many other things may be tested only with 8.
If that doesn't work for you, you can build gcc-7 from source. The preparatory system admin work includes a dnf install, a build from source, an install of 7.4 gnu compiler, and a set up of paths for CUDA development only. If you have gnu gcc and g++ version 8 installed with the appropriate standard libraries and it works, the version 7 compiler can be installed with relative ease.
Browse and find the nearest mirror listed on https://gcc.gnu.org/mirrors.html and then copy the link location for gcc-7.4.0.tar.xz and place it in the shell variable u like this example.
u="http://mirrors.concertpass.com/gcc/releases/gcc-7.4.0/gcc-7.4.0.tar.xz"
Then you can do the rest as commands.
sudo dnf install libmpc-devel
cd
mkdir -p scratch
cd scratch
wget -O - "$u" |tar Jxf -
cd gcc-7.4.0
mkdir build
cd build
../configure --prefix=/usr/local/gcc-7
make
sudo bash -c "cd \"`pwd`\"; make install"
Then you execute this in the shells and tools you develop with. Do NOT put this in the system login apparatus or in .bashrc or .bash_profile, for the same reason as above. Other things may be tested with version 8 only. Instead place them in your development environment where they belong.
LD_LIBRARY_PATH=/usr/local/gcc-7/lib64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/gcc-7/lib:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/host/linux-desktop-glibc_2_11_3-glx-x64/Plugins:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/NsightCompute-1.0/target/linux-desktop-glibc_2_11_3-glx-x64:$LD_LIBRARY_PATH
LD_LIBRARY_PATH=/usr/local/cuda-10.0/targets/x86_64-linux/lib/stubs:$LD_LIBRARY_PATH
PATH=/usr/local/gcc-7/bin:$PATH
PATH=/usr/local/cuda-10.0/bin:$PATH
PATH=$HOME/big/cuda.samples/NVIDIA_CUDA-10.0_Samples/bin/x86_64/linux/release:$PATH

Related

Virtuoso appears to be installed... but isn't (and won't run)

I've followed the instructions to install the stable branch of Virtuoso Open Source 7 on Ubuntu 16.04. There don't appear to be any errors throughout the process of —
./autogen.sh
CFLAGS="-O2 -m64"
export CFLAGS
./configure
make
make install
However, when I go to /usr/local/virtuoso-opensource/var/lib/virtuoso/db (which contains only virtuoso.ini) and run —
virtuoso-t -f &
The first time I do this the terminal just vanishes. When I reopen the terminal and run the same again it just reads The program 'virtuoso-t' is currently not installed. You can install it by typing: apt install virtuoso-opensource-6.1-bin.
I've tried installing both 7 stable and develop from github and both produce the same result. I'd rather use 7 but tried installing 6 via the ubuntu package and conductor wouldn't work for me - not having much luck all round, one of those days.
Thanks for assistance you can provide.
Sounds like you didn't adjust your $PATH variable after make install.
$PATH should include the path to the directory which contains the virtuoso-t, or you can include that path in the launch command, e.g. —
/path/to/virtuoso-t -f -c /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.ini &
(Note that the develop/7 branch is recommended over stable/7 at the moment, due to the number of fixes there.)

Instaling cross-compiled debian packages to fake "footfs" with dpkg

The setup I have is like this: I have two sets of libraries that are compiled for amd64 (pc) and armelx (ARM). They are both used to cross-compile some software on a build machine.
The first ones (amd64) can be updated without hassle by updating the apt-repository and using apt-get install on the build machine. The packages for ARM however, I don't want to install with apt, because it does not support installing to different directory. If I installed to default directories, the versions could not coexist. Right?
So far, the build machine was updated manually each time there was a new version of the packages, simply by extracting with dpkg -x to a dedicated "fake" footfs directory. This is where the compiler would also look when cross compiling other SW. The problem is, there is no information about these extracted packages or their versions anywhere on the system, right? It should have been in the status file.
My thought was to have these packages installed on this footfs dir with dpkg -i <package.deb> --root=<rootfs>. Would this work? I have a feeling it will not, because the deb packages have no post/pre-remove/install scripts, so it may work for a virgin install somehow, but not for upgrading? Also, what must the rootfs directory structure look like and what must it contain in order for this to work even the first time? Is there a tool to help with this?
Thanks.
Once you have a base armel Debian system, you can actually enter it and run the armel code inside it using something like QEMU. The qemu-arm-static tool (in the qemu-user-static package) can make use of the binfmt_misc capability in Linux to make it so ARM executables are directly run under the QEMU ARM system emulator. So you can run dpkg, apt-get, and so on inside the armel "rootfs" while running on amd64 hardware.
Example:
my_arm_system=/mnt/arm_system
sudo cp /usr/bin/qemu-arm-static "$my_arm_system/usr/bin/"
sudo chroot "$my_arm_system" apt-get update
sudo chroot "$my_arm_system" apt-get install $somepkg
sudo chroot "$my_arm_system" /bin/bash
As for setting up the base armel system in the first place: Debootstrap is the typical method for setting up a Debian base system, whether in a chroot or otherwise. You can use it for installing a base system of a different architecture, but it takes a few extra steps:
distro=jessie # or whatever
echo "Debootstrap phase 1"
sudo mkdir "$my_arm_system"
sudo debootstrap --arch=armel --verbose --foreign "$distro" "$my_arm_system"
sudo cp /usr/bin/qemu-arm-static "$my_arm_system"/usr/bin/
echo "Debootstrap phase 2"
sudo chroot "$my_arm_system" /debootstrap/debootstrap --second-stage
Multistrap is another tool that might be useful; it is intended for setting up Debian environments of one architecture on a host of a different architecture, or for using more complicated APT source combinations. It's not perfect, as it doesn't follow all the deb installation "rules" exactly. It takes some shortcuts/deviations in order to make its job reasonably possible.

How to install ADA IDE and compiler on mac (OSX)?

I downloaded GNAT ADA GPL 2014 and now trying to install on my Mac.
The directions below are the ones I am following, but I do not know where to look to find the file called doinstall. I might still need some help after finding it, but can anyone help me out here?
Navigate to the directory that contains a file called: doinstall
Enter: sudo mkdir /usr/local/gnat
Enter: sudo ./doinstall
Update your path as needed for your shell
You should have downloaded gnat-gpl-2014-x86_64-darwin-bin.tar.gz.
Go to some temporary directory (I use ~/tmp):
cd ~/tmp
Unpack the download, which creates a directory gnat-gpl-2014-x86_64-darwin-bin containing the binary distribution to be installed:
tar zxvf ~/Downloads/gnat-gpl-2014-x86_64-darwin-bin.tar.gz
Enter that directory, which contains (amongst others) doinstall:
cd gnat-gpl-2014-x86_64-darwin-bin
Execute doinstall to enter the installation dialog:
sudo ./doinstall
Remove the unpacked download:
cd ..
rm -rf gnat-gpl-2014-x86_64-darwin-bin
Now you can update PATH as needed for your shell.
What Simon Wright said is correct, but if you're running on Yosemite there's an extra problem: for some obscure reason, Adacore GNAT is broken on Yosemite. You have to make it think it's compiling for Mavericks:
export MACOSX_DEPLOYMENT_TARGET=10.9 # Yosemite workaround
That can go in a few different places, but I put it near the top of the /usr/local/gnat/bin/gps script so it doesn't interfere with the xcodebuild environment.
Also, I found GTKAda to be nearly impossible to install from source; if you download the XNAdaLib-GPL package from http://sourceforge.net/projects/gnuada/ you can install that and get everything you need without having to wade through Adacore's mess. (You may want to use the Adacore version of Glade for GUI design though; for some reason the Sourceforge package's version is localized in French and I'm not sure if it can be switched to English.)
Finally, since this is a bit duct-tape-and-baling-wire, I would recommend not shipping any production mission-critical code with this environment; either roll back to Mavericks or wait for GNAT 2015.

libcrypto.so.10: cannot open shared object file: No such file or directory

I am trying to install ODBC driver for Debian arrording to these instructions: https://blog.afoolishmanifesto.com/posts/install-and-configure-the-ms-odbc-driver-on-debian/
However trying to run:
sqlcmd -S localhost
I get the error
libcrypto.so.10: cannot open shared object file: No such file or
directory
What could be the cause?
So far I have tried
1.
$ cd /usr/lib
$ sudo ln -s libssl.so.0.9.8 libssl.so.10
$ sudo ln -slibcrypto.so.0.9.8 libcrypto.so.10
2.
/usr/local/lib64 to the /etc/ld.so.conf.d/doubango.conf file
3.
sudo apt-get update
sudo apt-get install libssl1.0.0 libssl-dev
cd /lib/x86_64-linux-gnu
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10
4. Sudo apt-get install libssl0.9.8:i386
None of these have helped.
As I'm quite familiar with Debian and programming, here is some advice:
if you have questions about setting up your system, ask on SuperUser and/or (if your question is specific to a Un*x flavour) on Unix&Linux
when fuddling around with symlinks to shared-libraries, you should have a thorough understanding of what you are doing. these files are named for a reason - and the reason is to protect you (the user of the system) from weird crashes, because an application is using a wrong/incompatible library.
a tutorial that tells you to do so, should give proper warning and explanation about what you are to do.
So, why are these instructions in the tutorial you are following?
The application you are trying to run, has been linked against libcrypto.so.
On the developer machine (that was used to produce the application binary), libcrypto.so was a symlink to libcrypto.so.10, but this is missing on Debian: maybe because the library has been removed (and replaced by a new and incompatible version), or because Debian uses a different naming scheme as compared to the system that was used to compile the application.
If it is the former, then you cannot solve the issue by using symlinks.
You have to get the right library (or the application linked against the correct libraries).
If it is the latter, you may get away with symlinking the expected library name with the correct library files found on your system. (This is assuming that the only difference between the two systems is indeed the so-naming scheme).
So, how to do it?
first of all, you should find out, against which libraries your application was really linked, and which of these libraries are missing.
$ ldd /path/to/my/app | grep -i "not found"
libfoo.so.10 => not found
then find out, whether you have a (hopefully compatible) library on your system. A good place to start is /usr/lib/. but not-so-recently, Debian has started moving the libraries to /usr/lib/<host-triplet>, with <host-triplet> describing a target architecture. You can find out the default value if your application was indeed built for the architecture you are running (e.g. for linux-amd64) you can get the string by running something like:
$ gcc -print-multiarch
Imagine you discover that you have /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0.
if you have good reason to believe that this can act as a replacement for libfoo.so.10, you can go make the found library available to your application by means of a symlink, e.g.
# cd /usr/local/lib/
# ln -s /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0 libfoo.so.10
Finally, you might need to refresh the cache of the dynamic linker so it starts using the new library, by running ldconfig as root/superuser.

Compiling OpenCL on Ubuntu

My programming experience is about 1 year of C/C++ experience from high school, but I did my research and wrote a simple program with OpenCL a few months ago. I was able to compile and run this on an Apple computer relatively easily with g++ and the --framework option. Now I'm on my Ubuntu machine and I have no idea how to compile it. The correct drivers have been downloaded along with ATI's Stream SDK (I have an ATI Radeon HD5870). Any help would be appreciated!
Try
locate libOpenCL.so
If it is in one of the standard directories (most likely /usr/lib, or /usr/local/lib) you need to replace "--framework OpenCL" with "-lOpenCL". If g++ cannot find the lib you can tell g++ to look in a specific directory by adding "-L/path/to/library".
I wish I had my Linux to be more helpful... It is probably best if you redownload the ati-stream-sdk, after extracting it, open the Terminal and "cd /path/to/extracted/files"; in that directory execute make && sudo make install
make you probably know this from windows, this compiles, whatever needs to be compiled
&& chains commands together, the following commands will only be executed if the first command succeeded
sudo make install this will put the files in the expected places (sudo executes a command with superuser priviledges, you will have to enter your password)
Hope that helps.
You might be missing the dynamic libraries from the dynamic linker configuration.
Search for where the libraries are. Most likely /usr/lib, or /usr/local/lib.
Make sure the path location is also configured at one of these places:
LD_LIBRARY_PATH - you can set it in you environment shell, like .bashrc
/etc/ld.so.conf - you will need to call ldconfig to update the cache and it requires root access to change the file.
Reason
Aside from #bjoernz, my system can't find the libOpenCL.so file
It's because the correct file directory is missing
After searchig over the internet, I found out that libOpenCL.so file can provided by ocl-icd-opencl-dev package
Solution
You just need to install the package mentioned above by typing into cmd
sudo apt update
sudo apt install ocl-icd-opencl-dev
Therefore, libOpenCL.so can be found under /usr/lib/x86_64-linux-gnu/ folder
My System Information
OS: Ubuntu 16.04 LTS
GPU: NVIDIA GeForce GTX 660
GPU Driver: nvidia-375
OpenCL: 1.2
Reference:
[1] How to install libOpenCL.so on ubuntu
[2] How to set up OpenCL in Linux

Resources