CUDA 5.0 on a Slackware64 current with gcc 4.7 - gcc

When I try to directly install the binary (700mb) cuda_5.0.35_linux_64_fedora16-1.run I only get the driver installed and setup detect that I have unsupported gcc version 4.7. I have nvcc and gcc-4.5.2 on my path.
Thus I configured and installed gcc 4.5.2 to another directory (/opt/gcc) and pointed it via install script :
./cudatoolkit* --compiler-bindir /opt/gcc-4.5.2/usr/bin
I only got the deviceQuery working but for other codes in samples I have this ;
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
Thus the question is reduced to ;
CUDA 5.0 prod. release supports up to gcc 4.5 and I have 4.7 in stock by default. What is the proper (de facto) way of installing the secondary gcc to a different location and pointing to it from cudatoolkit install package ? Goal is to (obviously) seamless compile the samples folder in the latest CUDA release.
Older versions worked fine but I want to make this work.
Any suggestions are welcomed.

The steps used to get this working were:
Install gcc-4.4.7 to a different location
Install CUDA 5.0 to it's default location
Install Samples and SDK to your home directory
Add gcc-4.4.7 to your path (overwrite gcc-4.7.1)
Add LD_LIBRARY_PATH to your path
Add nvcc (/usr/local/cuda-5.0/bin) to your path
Compile (make) samples

Related

Looking for a mingw-w64 build of gcc that includes mudflap

I'm trying to debug a segfault in some code built with mingw-w64's version of gcc. Since no Windows build of gcc includes the Address Sanitizer, I've been looking for a version prior to 4.9 that would allow me to use Mudflap instead.
(It has to be 4.8 or earlier, since Mudflap was removed from gcc in 4.9 - see https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging)
I've tried using downloads of 4.8.1 and 4.6.4 from https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/ - but my builds all fail with cc1plus.exe: fatal error: mf-runtime.h: No such file or directory.
I have tried using the original MinGW as well, but 4.5 as downloaded from
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.5.0-1/
just fails silently with error code 1.
Is there any site that still hosts a mingw-w64 build of gcc old enough to include mudflap? Preferably with SEH threads instead of SJLJ. If not, is there anywhere I can download a mingw-w64-compatible set of libraries and headers to install mudflap to work with an existing build?

Cannot build Boost with MinGW

I just downloaded the latest versions of MinGW and Boost 1.54.0 (on Windows 7).
The first one installed smoothly (g++ 4.7.2).
When installing Boost, this is all I get:
boost_1_54_0> bootstrap.bat mingw
Building Boost.Build engine
The system cannot find the batch label specified - Test_Option
\CMake was unexpected at this time.
The compiler's path is set (from any directory, g++.exe --version returns 4.7.2).
Is there anything wrong in the way I specify MinGW?

Unable to build rapidjson tests on Mac OS X

I am trying to build the tests for rapidjson 0.11 (http://code.google.com/p/rapidjson/) on Mac OS X . It includes three projects: gtest (builds fine), unittest (build fails), and perftest (build fails), and when building make error out with Error 1 and Error 2.
The compiler output shows the following errors for both unittest and perftest which causes make to fail:
../../include/rapidjson/reader.h: In function ‘const char* rapidjson::SkipWhitespace_SIMD(const char*)’:
../../include/rapidjson/reader.h:116: error: ‘_SIDD_UBYTE_OPS’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_CMP_EQUAL_ANY’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_BIT_MASK’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_NEGATIVE_POLARITY’ was not declared in this scope
These pre-processor constants are related to SSE4 instructions. rapidjson can use SSE2 or SSE4.2 to speed it up, and it defaults to using SSE4.2 when building.
The makefile includes the -msse4.2 compiler switch to enable SSE4.2 support, and looking through the header files reveal that on OS X, both SSE4_1 and SSE4_2 pre-processor constants need to be defined for the SIDD... constants to be defined. For some reason, these SIDD... constants aren't being defined.
Further research showed that the -msse4 switch enables support for both SSE4.1 and SSE4.2, so I tried chaning the switch to -msse4, but it still errors out.
Not sure if the -msse4.2 switch automatically defines SSE4_2 , but I tried manually defining it, and sill no luck.
NOTE: If you want to try building it yourself on Mac, you will need to download a different premake script file, as the included one doesn't work. You can download the corrected script from the attachment on the second post here https://code.google.com/p/rapidjson/issues/detail?id=54
Any ideas on how to get it building successfully on OS X ?
Short answer - I had an older version of gcc (4.2) which didn't support -msse4.2 flag (it was introduced in gcc 4.3).
After upgrading to the latest version of gcc, the above issue disappeared:
Check which version of gcc is active with by opening a terminal and
running gcc -v
Download MacProst installer for your version of OS X from http://www.macports.org/install.php and run installer (easy way to upgrade GCC version)
Open new terminal window (must be new as PATH environment var is updated after MacPorts
install)
Check which versions of gcc you already have installed with port select --list gcc (NOTE: you probably won't have some of the later versions installed already. See next step)
Install latest version of gcc (gcc47 at the moment) with sudo port install gcc47 (this will take a while to download)
Run port select --list gcc again and you should see the new version in the list (eg. mp-gcc47)
Select this latest version as active gcc version with sudo port select gcc mp-gcc47
Run gcc -v again to check the latest version is active
With the compiler sorted, the first attempt to build rapidjson for release32 gave me errors about the limits header file due to __int128 not being defined for 32-bit builds`. Gnu's official position is that you need to roll your own. See answers at following link for more info:
Compiling 32bit binary: expected unqualified-id before '__int128'
Building for release64 or debug64 solved this issue, but it still failed to build due some warnings about casting away qualifiers in test/unittest/readertest.cpp:187:4. As the make file included the compiler flag -Werror=cast-qual, these warnings were treated as errors. Removing this flag in both unittest and perftest makefiles solved this issue (not ideal solution but I just wanted to get it building).
There were still linker warnings as the /usr/lib64 folder didn't exist, and the makefiles included the flag -L/usr/lib64, but the build was still successful.
SUCCESS - Both unittest_release_x64_gmake and perftest_release_x64_gmake ran without problems!
NOTE: rapidjson build instructions are included in the readme file in the ZIP archive.

configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+

I am attempting to build GCC-4.7.0 on a MacBook Pro running OS X 10.7.4. However, I am continuing to experience the same error:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.
This error occurred after running the following line:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/
To get rid of this error I have tried the following actions:
Using homebrew I downloaded gmp-5.0.4, mpc-0.21, and mpfr-3.1.0. At this point I attempting to point to where gmp, mpc, and mpfr are located with the following command:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/ --with-mpfr=/usr/local/Cellar/ --with-mpc=/usr/local/Cellar/
However, this caused the same error. So, I tried pointing gcc to various locations around the Cellar directory:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/ --with-mpfr=/usr/local/Cellar/mpfr --with-mpc=/usr/local/Cellar/mpc/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/5.0.4/ --with-mpfr=/usr/local/Cellar/mpfr/3.1.0/ --with-mpc=/usr/local/Cellar/mpc/0.21/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/5.0.4/include/ --with-mpfr=/usr/local/Cellar/mpfr/3.1.0/include/ --with-mpc=/usr/local/Cellar/mpc/0.21/share/
In the end these all produced the same error. I then downloaded the versions of gmp, mpc, and mpfr linked from the gcc error message (found here: ftp://gcc.gnu.org/pub/gcc/infrastructure/). After building these from the source and running all the same configurations I am left with the same problem. The configurations I have tried with this installation are:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/local/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/include/ --with-mpfr=/usr/local/include/ --with-mpc=/usr/local/include/
Then I read somewhere that there could be a problem if I didn't explicitly set the configuration to run in 64-bit mode. So, I tried all of these configurations again with the added setting of 'CC=gcc -m64'. But this didn't change anything. If anyone has any ideas I would be greatly appreciative.
If you don't know how to build and properly direct GCC's configure to the libraries you can put them in the source tree of GCC itself:
/some/dir/source/gcc/[libstdc++|libgomp|gcc|libiberty|....]
/some/dir/source/gcc/gmp/[configure|...]
/some/dir/source/gcc/mpfr/[configure|...]
/some/dir/source/gcc/mpc/[configure|...]
So without the version number appended. Then just run GCC configure without any arguments related to GMP/MPC/MPFR.
I've faced the same issue and it was easily solved by installing the corresponding development packages: gmp-devel, mpfr-devel and libmpc-devel
Yigal
EasyBuild (a tool to make building software easier) can be of help here. It comes with a small easyconfig file that specifies which GCC version to build, and which features to enable (see for example https://github.com/hpcugent/easybuild/blob/master/easybuild/easyconfigs/g/GCC/GCC-4.7.0.eb).
Once you've downloaded EasyBuild and configured it, you can just run
$EBHOME/easybuild.sh myGCC.eb
with EBHOME set to the location where you unpacked EasyBuild, and myGCC.eb a copy of the example GCC easyconfig, which you modified to your needs.
This command will download the GCC source tarball for you and build/install it, after doing the same to any dependencies, for example GMP, MPFR and MPC, saving you a lot of headaches.
For more information on EasyBuild, see https://github.com/hpcugent/easybuild/wiki .

How do /usr/include files (e.g. string.h) relate to gcc version?

I have a Kubuntu 11.10 system with Eclipse-CDT Indigo. gcc-4.6 was installed along with Eclipse. I have since installed gcc-4.4 and gcc-4.2 via Ubuntu packages.
I can switch the /usr/bin/gcc symlink to 4.4 or 4.6 and Eclipse builds my code either way. However when I set the symlink to use gcc-4.2 I get the following error (and many more):
In file included from /usr/include/c++/4.2/cstring:52,
from /usr/include/c++/4.2/i486-linux-gnu/bits/c++locale.h:47,
from /usr/include/c++/4.2/iosfwd:45,
from /usr/include/c++/4.2/ios:43,
from /usr/include/c++/4.2/ostream:45,
from /usr/include/c++/4.2/iostream:45,
from ../ProjStructure.h:4,
from ../Scanner.h:3,
from ../Scanner.cpp:1:
/usr/include/string.h:29: error: ‘__BEGIN_DECLS’ does not name a type
So it appears that the string.h I have in /usr/include expects __BEGIN_DECLS to be defined by one of the compiler specific includes.
/usr/include/string.h comes from the libc6-dev package, which does not seem to have compiler specific versions. I expected the package system to handle this and install all the right versions of things.
I've read the GNU documents on multiple versions of GCC, but they don't say anything about include files/directories.
What am I doing wrong here?
From which Ubuntu is your gcc-4.2 package?
It is probably from an older Ubuntu release. New Ubuntu releases have changed some header and library directories, which break older compilers.

Resources