I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Reference:
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
Related
I work on CentOS 5.5 and my computer used gcc-4.1.2 until now, and under /usr/lib/gcc/x86_64-redhat-linux/ there were 2 indexes: 4.1.1 and 4.1.2. For using some softwares I must update the gcc.
But after I installed gcc-4.7.0 from the downloaded gcc-4.7.0.tar.gz (I did not use yum because when I tried it all servers told me that I had the latest version which was certainly not true, and perhaps this was also caused by the problem I now face with), the /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ was created just like the 4.1.1 and 4.1.2 index, so under /usr/lib/gcc/x86_64-redhat-linux/ there were 3 indexes: 4.1.1, 4.1.2 and 4.7.0. And under /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ there were 6 indexes:
bin include lib lib64 libexex share
It looked like that 4.7.0 was successfully installed but when I ran
gcc --version
the result was still
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I also ran
update-alternatives --install /usr/bin/gcc gcc /usr/lib/gcc/x86_64-redhat-linux/4.7.0 40
to raise the priority of 4.7.0, and when I ran
update-alternatives --config gcc
it said
There is 1 program that provides 'gcc'.
Selection Command
-----------------------------------------------
*+ 1 /usr/lib/gcc/x86_64-redhat-linux/4.7.0
Enter to keep the current selection[+], or type selection number:
And I printed 1, all it looked like that 4.7.0 was selected as the default gcc, but when I ran gcc --version, the result was not changed! Still 4.1.2.
After that I even removed all 4.1.2 gcc and its related programs by rpm -e and deleted the index, but the result of gcc --version became
-bash: gcc: command not found.
It didn’t change when I reinstalled the 4.7.0.
After all, when I looked for the links of /usr/bin/gcc/ I found
/usr/bin/gcc -> /etc/alternatives/gcc
and link of /etc/alternatives/gcc was
/etc/alternatives/gcc -> /usr/lib/gcc/x86_64-redhat-linux/4.7.0
this should be the result of my running the update-alternatives line, so it has worked. It did make the link to 4.7.0. So why didn’t this link call 4.7.0 in the end? I can’t find out.
I even made the direct link to 4.7.0 then:
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
however this still didn’t work.
I am very confused with it. I will be grateful for your help. Thank you very much!
p.s. Thank Basile Starynkevitch very much for noticing me to make these explanations:
I have /usr/bin/ in my PATH, so this should be OK.
I am teached that /usr/bin/gcc/ should be linked to an executable but not index, so the link to 4.7.0 is wrong. But could anyone tell me which executable to link to, or which executable is /usr/bin/ linked to in a common computer? This may very likely lead to the solution to the problem.
I cannot run configure one more time because configure itself requires gcc but now it is not found. So I'm afraid the problem cannot be fixed by that.
Be aware of the PATH variable. You could have some $HOME/bin/ in it.
Restore your system's gcc (so undo all the mess you have done). Then run which gcc and gcc -v to understand what is it exactly.
If you compile GCC from its source code (as distributed by the FSF), choose a recent version, e.g. GCC 8 in fall 2018.
Read carefully about installing GCC. Compile it outside of its source code. Be aware of the many configure options. I suggest to consider configuring it with some --program-suffix option (such as --program-suffix=-8) and then adding symlinks (e.g. $HOME/bin/gcc -> /usr/local/bin/gcc-8) appropriately.
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
it is wrong. Since /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ is some internal directory, and /usr/bin/gcc has to be an executable.
You probably don't need to run update-alternatives, but you do need to add (cleverly) something in a directory mentioned in your PATH
See also this answer to a similar question.
after edits in the question
You need first to clean up the mess you did under /usr/ (in particular in /usr/bin/ which you should never change without your package system). Remove all the things you added under /usr/bin/ and /usr/lib/. Then re-install forcibly and explicitly appropriate system gcc packages (using yum or some other package manager).
I have /usr/bin/ in my PATH, so this should be OK.
Probably not. My recommendation is to have $HOME/bin/ and /usr/local/bin/ early in your PATH (so before /usr/bin/; you might need to edit ~/.bashrc to change your PATH setting) and to add your new gcc, as something like gcc-8 (if you compile GCC 8 from its source code), there. If you want a system wide installation, have some /usr/local/bin/gcc-8 program. If you want a personal installation, have some $HOME/bin/gcc-8 program (both could be absolute symlinks to somewhere else).
I am running the latest version of MinGW GCC 4.7.2, and it was working fine with -std=c++11 before I installed Haskell using Haskell Platform. Please take a look at this:
For some reason, the GCC went back to 4.5.2, after installing Haskell, I re-installed it, with version 4.7.2, but its still showing 4.5.2.
Haskell adds its own GCC to your system PATH. You can check this is true by running
where gcc
which will show two commands, the Haskell one first, followed by your MinGW GCC.
The solution is to change your PATH to point to the GCC you want (but make sure Haskell still uses its GCC, I doubt it'll agree with GCC 4.7 if it came with GCC 4.5).
The easiest is to have some script ou can run to set up your compilation environment, so you don't have to worry about system PATHs.
If you don't care much about that exact GCC version you had installed, you can get my builds (32-bit and 64-bit), which come with a .cmd file you can doubleclick and it will give you a build environment much like the MSVS commandline shortcut, but for GCC. All it really does is add the compilers to PATH.
I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Reference:
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
I am trying to compile the Boost 1.48 in CentOS 5.6. I need the files to be in this format:
boost_program_options-gcc41-mt-1_48
I am compiling with this bjam flags:
./b2 -q --toolset=gcc --layout=tagged --without-mpi install
but it still don't add the gcc prefix to the name.
How can I fix this?
For me (although I use darwin toolset instead of plain gcc) Bjam creates files with names, like:
libboost_program_options-xgcc42-mt-1_49.a
Create the site-config.jam or user-config.jam file, which defines your custom version of GCC toolset, as described in 'Configuration' section of the Boost.Build documentation.
Additionally, there is an example, which suggests, that standard GCC toolset has version names defined as numbers only, without the gcc prefix.
Boost output filenames are generated, by the tag rule in boostcpp.jam. You can check there, if the above solution would be insufficient
For some reason, I should use gcc to compile a C file, then link against Visual C++ 2008 project.
(I used the current latest gcc version: cygwin gcc 4.3.4 20090804.)
But there is one problem: gcc always allocate a big array with _alloca,
and VC linker can't resolve the symbol __alloca.
for example,
int func()
{
int big[10240];
....
}
this code makes the _alloca dependency although I didn't call the _alloca function explicitly.
(array size matters. if i change 10240 -> 128, everything ok)
I tried gcc option -fno-builtin-alloca or -fno-builtin, but no luck.
Is it possible to make gcc not to use _alloca ? (or adjust the threshold?)
Best thing to do would be to compile all code with VC++. If that's not possible..
You should use the mingw gcc instead of the cygwin one. It's designed to output code that will be linked against the VC++ runtime, not the cygwin libraries. In particular, it will call the VC++ runtime function __chkstk instead of __alloca.
You could just write your own _alloca routine and link against that. Look at the gcc library source to see what it's supposed to do.
It looks like _alloca has been deprecated by Microsoft and is no longer in their runtime libraries after VS2005. Newer runtime libraries support _malloca.
Your options don't look good. You can try to build with VS2005 instead. Perhaps cygwin has an option where you can tell it you are using a newer runtime library (and if they don't support that yet, you could file it as a feature request).
some related discussions:
cygwin: gcc and alloca
GNU Compiler Collection (GCC) Internals
gcc and alloca