This is a follow up Q to CUDA incompatible with my gcc version.
I've recently updated to Ubuntu 12.04 as well as grabbing the latest CUDA toolkit. My nvcc --version is showing: Cuda compilation tools, release 5.0 (My driver ver is 304.43.)
I'm trying to fix my build environment. I get errs about using GCC 4.6. I can probably fix this w/ the help of the above link. I'm wondering about the other 8 packages in this large project. Should I be concerned with building other pieces with one version of GCC-4.6 and my cuda stuff with GCC-4.5? I figure they should all be compatible, but I've never run into this before. Is this anything I need to be concerned with?
I have run into incompatibility issues with different versions of GCC.
Specifically, GCC 4.7 and 4.6. My Qt applications wouldn't compile for me, because I was using GCC 4.7, and the library was compiled against GCC 4.6. They compiled fine, and there seemed to be no problem at first. But then I ran into trouble actually running them.
I would recommend against using different versions of GCC in the same project.
Related
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
The question is about a specific combination of versions but is relevant more generally.
I've just dist-upgraded from Kubuntu 12.04 to 14.04. Now, when I want to compile CUDA code (with CUDA 6.5), I get:
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
I installed gcc-4.8 (and 4.7), and tried to use the symlinks-in-/usr/local/cuda/bin solution suggested here:
CUDA incompatible with my gcc version
but this doesn't work. What should I do?
This solution is relevant to multiple combinations of CUDA and GCC versions.
You can tell CUDA's nvcc to use a specific version of gcc. So, suppose you want gcc 4.7 for use with CUDA 6. You run:
sudo apt-get install gcc-4.7 g++-4.7
and then add the following switch to your nvcc command-line:
nvcc --compiler-bindir /usr/bin/gcc-4.7 # rest of the command line here
If you're building with CMake, add an appropriate setting before looking for CUDA to your CMakeLists.txt, e.g.:
set(CUDA_HOST_COMPILER /usr/bin/gcc-4.7) # -> ADD THIS LINE <-
find_package(CUDA)
Also, it seems clang can compile CUDA as well, maybe that's worth experimenting with (although you would have to build it appropriately).
Note: Some Linux (or other OS) distributions don't have packages for multiple versions of gcc (in the same release of the OS distribution). I would advise against trying to install a package from another release of the distribution on an older release, and consider building gcc instead. That's not entirely trivial but it is quite doable - and of course, it's your only option if you don't have root access to your machine.
Switch back to a supported config. They are listed in the getting started document for any recent CUDA distribution.
For your particular configuration you have currently listed, you might have better luck with CUDA 7 RC, which is now available to registered developers.
I had a similar issue with CUDA Toolkit 7.5 and gcc 5.2.1.
I did modify the host_config.h file in /usr/local/cuda/include/:
Just remove the lines where it check the gcc version. It did solve my problem.
Credits goes to Darren Garvey (https://groups.google.com/forum/#!topic/torch7/WaNmWZqMnzw)
Very often you will find that CUDA has had newer releases by the time you encounter this problem. For example, the original formulation of the question was about CUDA 6 and GCC 4.9; CUDA 7 supported GCC 4.9. CUDA 8 supports GCC 5.x . And so on.
I installed the GCC 4.8.2 a couple of weeks ago. The installation process went well and I have GCC 4.8.2 at my Ubuntu system (12.04 64 bits). Now GNU just released the newer version 4.9.0.
My question is: Is there any way to upgrade my GCC to 4.9.0 without doing all process: configuration, building, checking and installation from scratch?
Also, please tell me what is the benefit/purpose of gcc-4.8.2-4.9.0.diff.gz file?
Is it like script/patch file to upgrade my compiler?
FYI, I don't have any plan to have two different versions of GCC at my system.
My question is: Is there any way to upgrade my GCC to 4.9.0 without doing all process: configuration, building, checking and installation from scratch?
Yes, if you have it already built. No, if you have only sources.
Also, please tell me what is the benefit/purpose of gcc-4.8.2-4.9.0.diff.gz file?
Read manual for patch utility how to apply it. You can convert 4.8.2 sources to 4.9.0 ones with this diff.
Is it like script/patch file to upgrade my compiler?
Yes, but for its sources. So building is still required.
Do you really need new features of 4.9 for your projects?
I found that more and more open source libraries will use C++11 features, and my Ubuntu Desktop 12.04 just has gcc 4.6, I want to use the update-alternatives to change the default gcc version into 4.7 or 4.8. I wonder that, if the libraries in the /usr/local/lib compiled by gcc 4.6 will need to be recompiled by the new gcc 4.7/4.8. In my opinion, if the dependency libraries are still in the system, there is no need to recompile. But, If one dependency library compiled by the new gcc 4.7, is the dependency among libraries still right? Sorry for my poor English.
Thanks.
Just update to 13.04 (and soon 13.10). From my 13.04 development box:
edd#max:~$ ls -1 /usr/bin/g*-4.*
/usr/bin/g++-4.4
/usr/bin/g++-4.5
/usr/bin/g++-4.6
/usr/bin/g++-4.7
/usr/bin/gcc-4.4
/usr/bin/gcc-4.5
/usr/bin/gcc-4.6
/usr/bin/gcc-4.7
/usr/bin/gcc-ar-4.7
/usr/bin/gcc-nm-4.7
/usr/bin/gcc-ranlib-4.7
/usr/bin/gcov-4.4
/usr/bin/gcov-4.5
/usr/bin/gcov-4.6
/usr/bin/gcov-4.7
/usr/bin/gfortran-4.4
/usr/bin/gfortran-4.5
/usr/bin/gfortran-4.6
/usr/bin/gfortran-4.7
edd#max:~$
Make sure you upgrade one-by-one and not in jumps. It usually a very smooth process.
I am using Cent OS 5.
It has legacy package installed.
With what version of gcc should I compile ?
Does it really required to compile with old gcc version to support old linux os ?
if yes why ?
I'm going to start off by saying that the easiest way to get software builds that will work on CentOS 4, or even older, is to build the code on those target distributions, or ship your code with some scripts/tools to make it easy to recreate a build on that machine. If you've ever downloaded a source code release, and did the /.configure && make && make install steps, this is what I'm talking about.
Those source releases are built upon the GNU Autotools system, which gives you auto-configuration (it determines what can and can't be used on the target system) and generates a makefile to build with.
There are alternatives to the GNU Autotools system (which, frankly, I find a chore to learn and use), like cmake and scons. Here is a page (on scons) which compares the popular build tools:
http://www.scons.org/wiki/SconsVsOtherBuildTools
So what if you still want to build on your CentOS 5 machine for older CentOS installs?
Now for why you do need legacy libraries and compilers to build with, if you want to build on your CentOS 5 system:
So you have CentOS 5, which runs this toolchain:
gcc 4.1.2
glibc 2.5.x
libstdc++ 4.1.2
And CentOS 4, which runs this toolchain:
gcc 3.4.x
glibc 2.3.x
libstdc++ 3.4.x
The big problem is that if you were to just build C or C++ software with the standard CentOS 5 tools, they would be linked to the CentOS 5 C and C++ libraries (glibc, libstdc++, libgcc), and these libraries are not backward compatible with older releases. That is, software built for glibc 2.5.5 is in no way guaranteed to run with glibc 2.4, or even glibc 2.5.4 (though unless there are special circumstances, you would be able to run glibc 2.4-built software on glibc 2.5.x). You will also need to build the dependencies against the older library versions.
When you go even older, you will need to build a cross-compiler (look up crosstool) that will allow you to target builds for older systems, that will link to the older versions of libc and other dependencies built against that as well.
Is there something else besides building on the target and such?
You could static link all your dependencies into the binary, so you wouldn't have to worry about the dependencies and such. However, I have never done such a thing and I forget if there was some problem to linking glibc statically, or if I'm thinking of some other major library that posed issues with static linking (on a technical level).