I have recently become frustrated with the new clang compiler included with Xcode 5. I was wondering what the best way to install GNU GCC on OS X would be.
Things to consider:
I don't want to use MacPorts, fink, homebrew or any other third party package manager.
I would like to use the latest GCC, compiled from source, if possible.
I need the existing GCC (hardlink to clang) to remain the default, but to easily be able to use GNU GCC when I need to.
I would like to avoid modifying the code if at all possible.
EDIT: Success! Using GCC 4.9.2 (with GMP 5.1.3, MPFR 3.1.2, MPC 1.0.2, ISL 0.12.2, and CLooG 0.18.1) I succesfully built GCC. Tips to take from here:
Make sure you use ISL and CLooG. Yes, they are optional, but they make a more optimised compiler and I had trouble building without them. Make sure you use ISL 0.12, not the latest version (0.14).
If possible, use the standalone Developer Tools, not XCode. (XCode has some buggy headers, and while I didn't notice any issues building GCC I have had issues with other software (e.g. GPG)).
I recommend putting all your sources in the gcc directory, rather than building and installing separately (it's faster this way)
Make sure you invoke configure with CC=clang CXX=clang++ so GCC knows it isn't being compiled by GCC.
Definitely, definitely, definitely, invoke make with -j8, or otherwise the build will take about 4 hours! (With -j8, it took 1 1/3 hours on my Mid-2012 MBP with 8gb RAM.) (make -j8 means make can build 8 threads simultaneously (4 cores + HT), whereas on a 2-core machine you would run make -j4.)
Hope this helps!
Homebrew now has the GCC package so you can install it with this command:
brew install gcc
The way I do it is:
Download the source for GCC and numerous supporting packages. The instructions are in the gcc-4.x.y/INSTALL/index.html file in the GCC source code, or online at http://gcc.gnu.org/install/.
GNU Multiple Precision Library (GMP) version 4.3.2 (or later) from http://gmplib.org/.
MPFR Library version 2.4.2 (or later) from http://www.mpfr.org/.
MPC Library version 0.8.1 (or later) from http://www.multiprecision.org/.
ISL Library version 0.11.1 from ftp://gcc.gnu.org/pub/gcc/infrastructure/.
CLooG 0.18.0 from ftp://gcc.gnu.org/pub/gcc/infrastructure/.
Use a script to extract the source for GCC and the support libraries into a directory, create the object directory, and run the build.
This is the script I used for GCC 4.8.2:
GCC_VER=gcc-4.8.2
tar -xf ${GCC_VER}.tar.bz2 || exit 1
(
cd ${GCC_VER} || exit
cat <<EOF |
cloog 0.18.0 tar.gz
gmp 5.1.3 tar.xz
isl 0.11.1 tar.bz2
mpc 1.0.1 tar.gz
mpfr 3.1.2 tar.xz
EOF
while read file vrsn extn
do
(
set -x
tar -xf "../$file-$vrsn.$extn" &&
ln -s "$file-$vrsn" "$file"
)
done
)
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix=$HOME/gcc/gcc-4.8.2
make -j8 bootstrap
When that finishes, run the install too. Then add $HOME/gcc/gcc-4.8.2/bin (the name you specify in --prefix plus /bin) to your PATH ahead of /usr/bin.
With a decent MacBook Pro with a 5400 rpm spinning disk, it takes an hour or two to compile everything (using the -j8 option to make), and requires multiple gigabytes of disk space while compiling. SSD is nice when doing this (definitely faster)!
GCC 4.9.0 was released on 2014-04-22. I've installed it using basically the same process, but with CLooG 0.18.1 and ISL 0.12.2 (required updates) and GMP 5.1.3 (and 6.0.0a), MPC 1.0.2 (or 1.0.1) and MPFR 3.1.2 on Mac OS X 10.9.2 Mavericks and an Ubuntu 12.04 derivative. Beware that the gmp-6.0.0a.tar.xz extracts into directory gmp-6.0.0 (not gmp-6.0.0a as you might expect).
Between 2014 and 2017-09-27, I've built GCC versions 4.9.0, 4.9.1, 5.1.0, 5.2.0, 5.3.0, 6.1.0, 6.2.0, 6.3.0, 7.1.0 with only minor variations in the build script shown below for GCC 7.2.0 on macOS Sierra (10.12). The versions of the auxilliary libraries changed reasonably often.
macOS Sierra and High Sierra
On 2017-08-14, I used a minor variant of the script above to build GCC 7.2.0 on macOS Sierra 10.12 (using XCode 8 as the bootstrap compiler). One change is that CLooG doesn't seem to be needed any more (I stopped adding it with GCC 6.2.0). This is my current script:
#!/bin/bash
#export DYLD_LIBRARY_PATH=$(clnpath $(dirname $(dirname $(which g++)))/lib:$DYLD_LIBRARY_PATH)
unset DYLD_LIBRARY_PATH
TAR=/opt/gnu/bin/tar
VER_NUM=7.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
extract() {
echo "Extract $1"
$TAR -xf $1
}
if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.xz || exit 1
fi
(
cd ${GCC_VER} || exit
nbncl <<EOF |
gmp 6.1.2 tar.lz
isl 0.16.1 tar.bz2
mpc 1.0.3 tar.gz
mpfr 3.1.5 tar.xz
EOF
while read file vrsn extn
do
tarfile="../$file-$vrsn.$extn"
if [ ! -f "$tarfile" ]
then echo "Cannot find $tarfile" >&2; exit 1;
fi
if [ ! -d "$file-$vrsn" ]
then
(
set -x
extract "$tarfile" &&
ln -s "$file-$vrsn" "$file"
) || exit 1
fi
done
)
if [ $? = 0 ]
then
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix="${TGT_DIR}" \
CC="${CC}" \
CXX="${CXX}"
make -j8 bootstrap
fi
Make sure your version of tar supports all 4 different compressed file formats (.lz, .gz, .xz, .bz2), but since the standard Mac version of tar does that for me, it'll probably work for you too.
On 2017-09-27, I failed to build GCC 7.2.0 on macOS High Sierra 10.13 (using XCode 9 for the bootstrap compiler) using the same script as worked on Sierra 10.12. The immediate error was a missing header <stack>; I'll need to track down whether my XCode 9 installation is correct — or, more accurately, why it isn't correct since <stack> is a standard header in C++98 onwards. There's probably an easy fix; I just haven't spent the time chasing it yet. (Yes, I've run xcode-select --install multiple times; the fact that I had to run it multiple times because of network glitches may be part of the trouble.) (I got GCC 7.2.0 to compile successfully on 2017-12-02; I don't recall what gymnastics — if any — were required to get this to work.)
Time passes; version numbers increase. However, the basic recipe has worked for me with more recent versions of GCC. I have 7.3.0 (installed 2018-01-2), 8.1.0 (installed 2018-05-02), 8.2.0 (installed 2018-07-26), 8.3.0 (installed 2019-03-01) and now 9.1.0 (installed today, 2019-05-03). Each of these versions was built and installed on the current version of macOS at the time, using the current version of XCode for the bootstrap phase (so using macOS 10.14.4 Mojave and XCode 10.2.1 when building GCC 9.1.0)
Use a pre-compiled binary specifically for OS X 10.9.x Mavericks:
→ gcc-4.9
Compiled using source code from the GNU servers.
This contains current versions (4.7 is the stable release) of gfortran
(free, open source, GNU Fortran 95 compiler), gcc (GNU C) and g++ (GNU
C++) compilers that can perform auto-vectorization (i.e. modify code
to take advantage of AltiVec/SSE, automatically) and other
sophisticated optimizations like OpenMP. For more information, see
this webpage.
Download my binaries, and cd to the download folder. Then gunzip
gcc-4.9-bin.tar.gz (if your browser didn't do so already) and then
sudo tar -xvf gcc-4.9-bin.tar -C /. It installs everything in
/usr/local. You can invoke the Fortran 95 compiler by simply typing
gfortran. You will also need to have Apple's XCode Tools installed
from the Mac App Store. With XCode 4 or 5 you will need to download
the command-line tools as an additional step. You will find the option
to download the command-line tools in XCode's Preferences.
On 10.9 Mavericks, you can get the command-line tools by simply typing
xcode-select --install.
Related
My ultimate goal is to get python package graph_tool working on my system and also on ipynb if possible. I have already brew install graph-tool, as indicated here, but that's still insufficient.
So I follow conda instructions here, and I make decent progress, until I encounter a compiler issue with the configuration.
$ conda create -n py36env python=3.6.3 anaconda
(py36env) $ conda install -c conda-forge cgal
... and so forth with the other required libraries
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ ./configure --prefix=/Users/tamtam/anaconda3/envs/py36env/ --with-python-module-path=/Users/tamtam/anaconda3/envs/py36env/lib/python3.6/site-packages
.
.
.
checking whether g++ supports C++14 features by default... no
checking whether g++ supports C++14 features with -std=gnu++14... no
checking whether g++ supports C++14 features with -std=gnu++1y... no
configure: error: *** A compiler with support for C++14 language features is required.
I'm not very familiar with compiler things, but I check my system as follows:
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ conda list | grep gcc
gcc 4.8.5 8
And outside of the conda env:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/tamtam/anaconda3/envs/py36env/bin/../libexec/gcc/x86_64-apple-darwin11.4.2/4.8.5/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure --prefix=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/
Thread model: posix
gcc version 4.8.5 (GCC)
And with Homebrew
$ brew list --versions | grep gcc
gcc 7.1.0 7.2.0
$ /usr/local/bin/gcc-7 --version
gcc-7 (Homebrew GCC 7.2.0) 7.2.0
$ echo $PATH
/Users/tamtam/anaconda3/bin:/Users/tamtam/anaconda/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
So my questions are: EDITS INCLUDED
1) What's the difference between the conda gcc 4.8.5 and Homebrew gcc 7.2 on my system? I'm confused because they're each up-to-date packages.
EDIT: Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem T.B.A.)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile (so ignore this)
2) I also have Xcode 8.3.3 that also comes with clang, which is what gcc is symlinked to... ?? No idea about the setup/relation
3) How can I adjust my system (for example, paths) so that the configuration process will detect a C++14 compiler? EDIT: resolved per 1)
(This solution is also included within the edits at the bottom of my question.)
Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile arises (so ignore this)
As a rule of thumb, if a product provides its own build tools (compiler, C headers, static libraries, include/library paths etc) instead of using the system's ones, you should use those when building things to use within its environment.
That's because, depending on include files, compiler, compiler version, compiler flags, predefined macros etc the same sources and libraries built with different toolchains can be binary incompatible. This goes double for C++ where there are no ABI standards at all. (In C, there are de facto ones for most platforms where there are competing compilers due to the need to do system calls.)
Now, what you have on your system:
The system's stock gcc (if any) is at /usr/bin (so includes are at /usr/include, static libraries at /usr/lib etc)
Homebrew's gcc 7.2 at /usr/local/bin (includes are probably at /usr/local/include)
Anaconda also has a gcc package that, if installed, would reside somewhere like /Users/<login>/anaconda3/envs/<env name>/bin
If an environment provides an own toolchain, it provides some way to make build scripts select that toolchain when building things. A common way is to set relevant environment variables (PATH, INCLUDE, LIB) - either directly or through some tool that the environment provides. Homebrew executables reside in /usr/local/bin which is always present in UNIX PATH as per the FHS; Anaconda adds itself to PATH whenever its environment is activated.
So, as you yourself guessed, since Anaconda provides its own gcc packages (thus enforces the compatibility of their output with its binary packages via package metadata - if there are known incompatibilities, the installation will fail due to requirement conflicts), you need to install one that meets graph-tool requirements -- which is gcc 5, available via gcc-5 package from salford_systems channel. Then specify --prefix as you already have.
You may need to install other dependencies, too, if you didn't already or you need optional features that they're required for.
I have XCode installed (Version 7.2.1 (7C1002)) in Yosemite and have downloaded and installed command line tools. When I try to check the gcc version I get:
$ gcc -v
Segmentation fault: 11
$
The output for:
$ type -a gcc
gcc is /usr/local/bin/gcc
gcc is /usr/bin/gcc
$
From what I understand, that should mean that I have it installed so I still don't understand why I can't check it's version. Since I will need gcc for other applications I would like to have it fixed...any suggestions? Do I need to link it somehow?
You have a faulty third-party version of gcc (or perhaps another compiler masquerading as gcc) installed in /usr/local. This may be something put there by Homebrew or maybe you installed this build of gcc yourself or something.
A short-term fix would be to modify your PATH environment variable so that /usr/bin comes before /usr/local/bin. Or, you could just always specify the full path to gcc, such as /usr/bin/gcc -v.
Longer term, you probably want to remove the broken gcc that's been installed to /usr/local. How you do that exactly depends on how you originally installed it there.
Building GCC (latest revision) on OS X 10.11.1 here, using the command line:
../gccx/configure --with-gmp="/opt/local" --with-mpfr="/opt/local" \
--with-mpc="/opt/local" --with-libiconv-prefix="/opt/local" --with-pkgversion="GCCX" \
--program-transform-name='s/^gcc$/gccx/; s/^g++$/g++x/' --enable-languages=c
Followed build instructions exactly, and getting this error:
g++ -std=gnu++98 -g -DIN_GCC -fno-strict-aliasing
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -Wl,-no_pie -o build/genmatch \
build/genmatch.o ../build-x86_64-apple-darwin15.0.0/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../build-x86_64-apple-darwin15.0.0/libiberty/libiberty.a Undefined symbols for architecture x86_64: "_iconv", referenced from:
convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o)
(maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv ) "_iconv_close", referenced from:
__cpp_destroy_iconv in libcpp.a(charset.o)
__cpp_convert_input in libcpp.a(charset.o) "_iconv_open", referenced from:
init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [build/genmatch] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make:
*** [all] Error 2
(A complete log is available at https://gist.github.com/3cb5d044533e657f4add.)
After investigating gcc/Makefile, it seems that the BUILD_CPPLIB variable does not include $(LIBICONV), since it is in a stage1 bootstrap at the time of the error. The relevant section is preceded by
# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled. For stage2+ use the host library and
# its dependencies.
Yet clearly the stage1 build of build/genmatch is referencing libcpp, which uses symbols from libiconv. So something is amiss here.
How can I fix it?
General discussion
Building GCC on Mac OS X is an occasionally fraught process. I've had various issues with various versions of GCC and various versions of Mac OS X over the years. You can see an earlier explanation of what I did in Install GCC on Mac OS X — that was for building GCC 4.8.x on Mavericks 10.9.x (or possibly Mountain Lion 10.8.x); it also reports success building GCC 4.9.0 on Mavericks 10.9.x, but failure to do so on Yosemite 10.10.x.
This is an updated recipe for building GCC 5.2.0 on Mac OS X 10.11.1 El Capitan.
It starts off using XCode 7.1.1 — I don't know which other versions of XCode are OK.
Note that El Capitan has a feature SIP (System Integrity Protection) that was not in Yosemite and earlier versions. This means you cannot create arbitrary directories under /usr any more. I used to install in /usr/gcc/vX.Y.Z; that is no longer permitted in El Capitan. One major change, therefore, is that I now install in /opt/gcc/v.X.Y.Z.
I've found that having DYLD_LIBRARY_PATH set is problematic — especially on El Capitan. In a major break from the past, I'm now not setting that at all. Note that the scripts unset it. Note too that the script explicitly sets the phase 1 compilers CC and CXX to /usr/bin/clang and /usr/bin/clang++ respectively (the XCode compilers). The current versions of GCC require a capable C++ compiler instead of (or as well as) a C compiler.
I have occasionally had problems with libiconv, but at the moment I've evaded them by not having my own version installed. Similarly, I've occasionally had problems with some awk scripts in the GCC source. I had to hack it/them to get it to work OK. However, with release copy of GCC 5.2.0 source, I seem to be able to build directly out of the box.
If you've only got a single disk partition, this next point isn't crucial. If you have multiple disks, either make sure the target directory does not exist or ensure that its name is exactly what you want. On the machines at work (not Macs but Linux machines, etc), I still use /usr/gcc/vX.Y.Z as the 'official' install location, but the software ends up in some arbitrary file system where there's enough space, such as /work4/gcc, and eventually there is a symlink such that /usr/gcc/vX.Y.Z gets to /work4/gcc/vX.Y.Z. However, it is crucial that /work4/gcc/vX.Y.Z does not exist while GCC is being compiled because it will resolve the name via realpath() or its equivalent and embed /work4/gcc/vX.Y.Z into the binaries, rather than the neutral name /usr/gcc/vX.Y.Z. This limits the portability of the installation; any other machine that it is moved to has to have a directory /work4/gcc/vX.Y.Z, even though you asked to install it in /usr/gcc/vX.Y.Z.
Compiling GCC 5.2.0 on Mac OS X 10.11.1 with XCode 7.1.1
I had to work with down-versions of both GMP (5.1.3 instead of 6.0.0a) and ISL (0.14 instead of 0.15). The builds for the later versions both caused me trouble.
Note that I put the library code for GMP, MPC, MPFR, ISL and Cloog (see the GCC pre-requisites) in the GCC source directory so that GCC builds its own versions of these libraries. I've found that its the simplest way to ensure that GCC locates these libraries correctly.
Target directory: /opt/gcc/v5.2.0
Build time was about 2h 15m on a 17" MacBook Pro (early 2011) running Intel Core i7 at 2.3 GHz, with 16 GiB 1333 MHz DDR3 main memory, and a 750 GB 5400 rpm hard disk drive. The source occupies about 850 MiB; the build tree ends up at about 4.6 GiB — you need plenty of disk space. The installed code ends up at about 420 MiB.
Script used — extract-gcc-5.2.0.sh
#!/bin/bash
unset DYLD_LIBRARY_PATH
TAR=tar
VER_NUM=5.2.0
GCC_VER=gcc-${VER_NUM}
TGT_BASE=/opt/gcc
TGT_DIR=${TGT_BASE}/v${VER_NUM}
CC=/usr/bin/clang
CXX=/usr/bin/clang++
extract() {
echo "Extract $1"
$TAR -xf $1
}
if [ ! -d "$GCC_VER" ]
then extract ${GCC_VER}.tar.bz2 || exit 1
fi
(
cd ${GCC_VER} || exit
nbncl <<EOF |
cloog 0.18.1 tar.gz
gmp 5.1.3 tar.xz
# gmp 6.0.0 tar.lz
isl 0.14 tar.bz2
# isl 0.15 tar.bz2
mpc 1.0.3 tar.gz
mpfr 3.1.3 tar.xz
EOF
while read file vrsn extn
do
tarfile="../$file-$vrsn.$extn"
if [ ! -f "$tarfile" ]
then echo "Cannot find $tarfile" >&2; exit 1;
fi
if [ ! -d "$file-$vrsn" ]
then
(
set -x
extract "$tarfile" &&
ln -s "$file-$vrsn" "$file"
) || exit 1
fi
done
)
if [ $? = 0 ]
then
mkdir ${GCC_VER}-obj
cd ${GCC_VER}-obj
../${GCC_VER}/configure --prefix="${TGT_DIR}" \
CC="${CC}" \
CXX="${CXX}"
make -j8 bootstrap
fi
Script nbncl — non-blank, non-comment lines
#!/usr/bin/env perl
#
# Non-blank, non-comment lines only
use warnings;
use strict;
while (<>)
{
chomp;
s/\s+$//;
s/\s*#.*$//;
print "$_\n" unless /^$/;
}
First, see Jonathan Leffler's very complete answer. I have a few more suggestions here.
The gcc configuration and build process needs to find your system's native header files and C run-time libraries. Newer, clang-based versions of Xcode hide these pretty deeply, and older versions of gcc don't seem to know how to find them. To get gcc 4.6 to build at all, I had to create these symlinks:
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include /usr
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/dylib1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o /usr/local/lib
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/bundle1.o /usr/local/lib
Your mileage will likely vary slightly: note that those pathnames underneath /Applications/Xcode.app/Contents have various version numbers baked in to them, which are likely to be different on your system.
(If, as Jonathan describes, the newest versions of MacOS don't allow you to put anything in /usr, you might have to create the /usr/include symlink in /usr/local/include, instead, and I suspect that would work, too.)
Also, this is mentioned elsewhere, but it's an unusual requirement, and easy to overlook: do not try to build gcc within its own source tree. Always create a build directory which is a parallel sibling, not a child underneath, of the directory into which you've extracted the gcc sources. That is, do not do this:
tar xzf gcc-x.y.z.tar.bz2
cd gcc-x.y.z # WRONG
mkdir build
cd build
../configure # WRONG
make
Instead, do this:
tar xzf gcc-x.y.z.tar.bz2
mkdir build
cd build
../gcc-x.y.z/configure
make
This is counterintuitive, I know, and it's not the way a lot of other packages work, but it definitely does work for gcc, and it's the recommended way to do it.
Another point: if you discover that your build is failing because you configured it improperly, such that you have to rerun configure with different options, it's safer to delete your entire build directory and start from scratch. The configure and build system sometimes, but it seems not 100% reliably, detects what might need rebuilding in that case. (Deleting and starting over is frustrating, I agree, but again, it can really save time in the long run.)
Finally, if you're trying to build a cross-compiler, see some additional suggestions and commentary at install gcc 4.6.1 on OS X 10.11 .
For what it's worth, MacPorts has ports for all recent versions that should be sufficiently easy for everyone (who knows how to code!) to read who doesn't want to install MacPorts but prefers to install the various dependencies mentioned here some other way.
A slightly tweaked personal version of the port for gcc 6.3.0:
https://github.com/RJVB/macstrop/blob/master/lang/gcc6/Portfile
The reason I mention that one (and post this answer) is that this tweaked version shows how to get G++ to use libc++ instead of libstdc++. That's a prerogative for being able to use G++ as a real replacement for clang++ that can be used without worrying about C++ runtime incompatibilities. This patch has allowed me to use g++ to build KDE (KF5) code and run it against Qt5 and the KF5 frameworks built with various clang compiler versions. (The patch files are in .../gcc6/files .)
Some explanation that might help interpreting the Tcl code of the linked file:
Ignore anything that's specific to $subport == "libgcc".
As you can see, you need gmp, mpc, mpfr and isl (the other dependencies should be of no interest if you're installing on your own).
The configure.args expressions construct the argument list to the configure script, configure.env and build.env add environmental variables for the configure and build (make) commands. Many of the configure options here are to ensure that the build uses dependencies from MacPorts but they'd probably be required too if you want or have to use a location not controlled by SIP and that isn't included in standard PATH definitions (the compiler still ought to work when invoked through a process that resets the path).
The configure and build are done in a build directory that sits next to the source directory, which makes it very easy to start over or just clean up without throwing away the sources.
After the configure step the build is done with "make bootstrap-lean" - which still creates about 1.7Gb of data in that build directory.
I'm trying to install GalSim on OSX Mavericks, using the anaconda python distribution, but keep running into the error:
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
the /usr/bin/env python is the anaconda one and there is indeed a libpython2.7.a in that libdir.
scons is installed via the conda package management system.
boost is installed manually as recommended via
./bootstrap.sh --with-python=/Users/harrison/anaconda/bin/python --with-python-root=/Users/harrison/anaconda/
./b2 -a link=shared
sudo ./b2 -a --prefix=/usr/local link=shared install
checking the version of python boost links to gives
$ otool -L /usr/local/lib/libboost_python.dylib
/usr/local/lib/libboost_python.dylib:
libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Is this correct (it doesn't seem so to me -- boost seems to be linking to the libpython2.7 in /usr/local/) and is this what is causing the problem installing GalSim?
Thanks
Ian
Full output:
$ scons
scons: Reading SConscript files ...
SCons is version 2.3.0 using python version 2.7.6
Python is from /Users/harrison/anaconda/include/python2.7
Using the following (non-default) scons options:
CXX = g++
These can be edited directly in the file gs_scons.conf.
Type scons -h for a full list of available options.
Using python = /usr/bin/env python
Using default PYPREFIX = /Users/harrison/anaconda/lib/python2.7/site-packages
Using compiler: /usr/bin/g++
compiler version: 4.2.1
Determined that a good number of jobs = 4
Checking for C++ header file fftw3.h... yes
Checking for correct FFTW linkage... yes
Checking for C++ header file boost/shared_ptr.hpp... yes
Checking for C++ header file TMV.h... yes
Using TMV_LINK file: /usr/local/share/tmv/tmv-link
-L/usr/local/Cellar/tmv-cpp/0.71/lib -ltmv -lblas
Mac version is 10.9
WARNING: The Apple BLAS library has been found not to be thread safe on
Mac OS version 10.7 (and possibly higher), even across multiple
processes (i.e. not just multiple threads in the same process).
The symptom is that `scons tests` will hang when running nosetests
using multiple processes.
If this occurs, the solution is to compile TMV either with a
different BLAS library (e.g. ATLAS) or with no BLAS library at
all (using WITH_BLAS=false).
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python...
Unable to build a python loadable module using the python executable:
/usr/bin/env python,
the library name libpython2.7.a,
and the libdir /Users/harrison/anaconda/lib/python2.7/config.
If these are not the correct library names, you can tell scons the
correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
Please fix the above error(s) and rerun scons.
Note: you may want to look through the file INSTALL.md for advice.
Also, if you are having trouble, please check the INSTALL FAQ at
https://github.com/GalSim-developers/GalSim/wiki/Installation%20FAQ
Ian, thanks for posting that. Based on the config.log and my own experience, I have an answer that should solve at least this problem (no guarantees that you won't hit something else later in the build).
The key problem here is that if you tell it the compiler is gcc (as is the default), it will try to use openMP. But actually invoking gcc on Mavericks gives you clang++, for which openMP doesn't work. So, you have to explicitly tell galsim that the compiler is clang++ so it won't try to use openMP. (The clue to this is in config.log, there are messages in various places about undefined symbols for x86_64 architecture... I had this problem on my own system when I started using Mavericks. See also https://github.com/GalSim-developers/GalSim/issues/493 )
So, please do scons CXX=clang++ and this problem should go away. I cannot guarantee that you won't hit a boost problem later on, however.
Please also see this question which has two suggestions which may help solve the problem for you as well.
I have troubles compiling some of the examples shipped with CUDA SDK.
I have installed the developers driver (version 270.41.19) and the CUDA toolkit,
then finally the SDK (both the 4.0.17 version).
Initially it didn't compile at all giving:
error -- unsupported GNU version! gcc 4.5 and up are not supported!
I found the line responsible in 81:/usr/local/cuda/include/host_config.h and changed it to:
//#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 6)
from that point on I got only a few of the examples to compile, it stops with:
In file included from /usr/include/c++/4.6/x86_64-linux-gnu/bits/gthr.h:162:0,
from /usr/include/c++/4.6/ext/atomicity.h:34,
from /usr/include/c++/4.6/bits/ios_base.h:41,
from /usr/include/c++/4.6/ios:43,
from /usr/include/c++/4.6/ostream:40,
from /usr/include/c++/4.6/iterator:64,
from /usr/local/cuda/include/thrust/iterator/iterator_categories.h:38,
from /usr/local/cuda/include/thrust/device_ptr.h:26,
from /usr/local/cuda/include/thrust/device_malloc_allocator.h:27,
from /usr/local/cuda/include/thrust/device_vector.h:26,
from lineOfSight.cu:37:
/usr/include/c++/4.6/x86_64-linux-gnu/bits/gthr-default.h:251:1: error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for
`pthread_create' instead. */" does not give a valid preprocessing token
make[1]: *** [obj/x86_64/release/lineOfSight.cu.o] Error 1
As some of the examples compile I reckon this is not a driver problem, but rather must have something to do with an unsupported gcc version. Downgrading is not an option as gcc4.6 has a whole system as a dependency at this point...
As already pointed out, nvcc depends on gcc 4.4. It is possible to configure nvcc to use the correct version of gcc without passing any compiler parameters by adding softlinks to the bin directory created with the nvcc install.
The default cuda binary directory (the installation default) is /usr/local/cuda/bin, adding a softlink to the correct version of gcc from this directory is sufficient:
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
Check the maximum supported GCC version for your CUDA version:
CUDA version
max supported GCC version
12
12.1
11.4.1+, 11.5, 11.6, 11.7, 11.8
11
11.1, 11.2, 11.3, 11.4.0
10
11
9
10.1, 10.2
8
9.2, 10.0
7
9.0, 9.1
6
8
5.3
7
4.9
5.5, 6
4.8
4.2, 5
4.6
4.1
4.5
4.0
4.4
Set an env var for that GCC version. For example, for CUDA 10.2:
MAX_GCC_VERSION=8
Make sure you have that version installed:
sudo apt install gcc-$MAX_GCC_VERSION g++-$MAX_GCC_VERSION
Add symlinks within CUDA folders:
sudo ln -s /usr/bin/gcc-$MAX_GCC_VERSION /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-$MAX_GCC_VERSION /usr/local/cuda/bin/g++
(or substitute /usr/local/cuda with your CUDA installation path, if it's not there)
See this GitHub gist for more information on the CUDA-GCC compatibility table.
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 then 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 affecting the rest of your system.
EDIT:
Note that this question, and answer, pertain to CUDA 4.
Since it was written, NVIDIA has continued to expand support for later gcc versions in newer CUDA toolchain release
As of the CUDA 4.1 release, gcc 4.5 is now supported. gcc 4.6 and 4.7 are unsupported.
As of the CUDA 5.0 release, gcc 4.6 is now supported. gcc 4.7 is unsupported.
As of the CUDA 6.0 release, gcc 4.7 is now supported.
As of the CUDA 7.0 release, gcc 4.8 is fully supported, with 4.9 support on Ubuntu 14.04 and Fedora 21.
As of the CUDA 7.5 release, gcc 4.8 is fully supported, with 4.9 support on Ubuntu 14.04 and Fedora 21.
As of the CUDA 8 release, gcc 5.3 is fully supported on Ubuntu 16.06 and Fedora 23.
As of the CUDA 9 release, gcc 6 is fully supported on Ubuntu 16.04, Ubuntu 17.04 and Fedora 25.
The CUDA 9.2 release adds support for gcc 7
The CUDA 10.1 release adds support for gcc 8
The CUDA 10.2 release continues support for gcc 8
The CUDA 11.0 release adds support for gcc 9 on Ubuntu 20.04
The CUDA 11.1 release expands gcc 9 support across most distributions and adds support for gcc 10 on Fedora linux
There is presently (as of CUDA 11.1) no gcc 10 support in CUDA other than Fedora linux
Note that NVIDIA has recently added a very useful table here which contains the supported compiler and OS matrix for the current CUDA release.
Gearoid Murphy's solution works better for me since on my distro (Ubuntu 11.10), gcc-4.4 and gcc-4.6 are in the same directory, so --compiler-bindir is no help. The only caveat is I also had to install g++-4.4 and symlink it as well:
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /usr/local/cuda/bin/g++
If using cmake for me none of the hacks of editing the files and linking worked so I compiled using the flags which specify the gcc/g++ version.
cmake -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6 ..
Worked like charm.
For CUDA7.5 these lines work:
sudo ln -s /usr/bin/gcc-4.9 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.9 /usr/local/cuda/bin/g++
Check out how to use "update-alternatives" to get around this issue:
... If you install gcc 4.6 you can also use the update-alternatives
command to allow for easily switching between versions. This can be
configured with:
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7
sudo update-alternatives --config gcc
On most distributions you have the possibility to install another gcc and g++ version beside a most recent compiler like gcc-4.7. In addition most build systems are aware of the CC and CXX environment variables, which let specify you other C and C++ compilers respectively. SO I suggest something like:
CC=gcc-4.4 CXX=g++-4.4 cmake path/to/your/CMakeLists.txt
For Makefiles there should be a similar way. I do not recommend setting custom symlinks within /usr/local unless you know what you are doing.
This works for fedora 23. The compat gcc repositories will be slightly different based on your version of fedora.
If you install the following repositories:
sudo yum install compat-gcc-34-c++-3.4.6-37.fc23.x86_64 compat-gcc-34-3.4.6-37.fc23.x86_64
Now make the soft links as mentioned above assuming your cuda bin folder is in /usr/local/cuda/
sudo ln -s /usr/bin/gcc-34 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-34 /usr/local/cuda/bin/g++
You should now be able to compile with nvcc without the gcc version error.
Gearoid Murphy's solution works like a charm. For me I had two directories for cuda -
/usr/local/cuda
/usr/local/cuda-5.0
The soft links had to be added only to the directory mentioned below -
/usr/local/cuda
Also, both g++ and gcc soft links were required as mentioned by SchighSchagh.
Another way of configuring nvcc to use a specific version of gcc (gcc-4.4, for instance), is to edit nvcc.profile and alter PATH to include the path to the gcc you want to use first.
For example (gcc-4.4.6 installed in /opt):
PATH += /opt/gcc-4.4.6/lib/gcc/x86_64-unknown-linux-gnu/4.4.6:/opt/gcc-4.4.6/bin:$(TOP)/open64/bin:$(TOP)/share/cuda/nvvm:$(_HERE_):
The location of nvcc.profile varies, but it should be in the same directory as the nvcc executable itself.
This is a bit of a hack, as nvcc.profile is not intended for user configuration as per the nvcc manual, but it was the solution which worked best for me.
CUDA is after some header modifications compatible with gcc4.7 and maybe higher version:
https://www.udacity.com/wiki/cs344/troubleshoot_gcc47
For people like me who get confused while using cmake, the FindCUDA.cmake script overrides some of the stuff from nvcc.profile. You can specify the nvcc host compiler by setting CUDA_HOST_COMPILER as per http://public.kitware.com/Bug/view.php?id=13674.
I had to install the older versions of gcc, g++.
sudo apt-get install gcc-4.4
sudo apt-get install g++-4.4
Check that gcc-4.4 is in /usr/bin/, and same for g++
Then I could use the solution above:
sudo ln -s /usr/bin/gcc-4.4 /opt/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /opt/cuda/bin/g++
In $CUDA_HOME/include/host_config.h, find lines like these (may slightly vary between different CUDA version):
//...
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9)
#error -- unsupported GNU version! gcc versions later than 4.9 are not supported!
#endif [> __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) <]
//...
Remove or change them matching your condition.
Note this method is potentially unsafe and may break your build. For example, gcc 5 uses C++11 as default, however this is not the case for nvcc as of CUDA 7.5. A workaround is to add
--Xcompiler="--std=c++98" for CUDA<=6.5
or
--std=c++11 for CUDA>=7.0.
If you encounter this error, please read the log file:
$ cat /var/log/cuda-installer.log
[INFO]: Driver installation detected by command: apt list --installed | grep -e nvidia-driver-[0-9][0-9][0-9] -e nvidia-[0-9][0-9][0-9]
[INFO]: Cleaning up window
[INFO]: Complete
[INFO]: Checking compiler version...
[INFO]: gcc location: /usr/bin/gcc
[INFO]: gcc version: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[ERROR]: unsupported compiler version: 9.2.1. Use --override to override this check.
Just follow the suggestion in the log file:
sudo sh cuda_<version>_linux.run --override
Job done :)
I just installed CUDA 10.2 with gcc 9.2 on Kubuntu 19.10 using the --override option.
For CUDA 6.5 (and apparently 7.0 and 7.5), I've created a version of the gcc 4.8.5 RPM package (under Fedora Core 30) that allows that version of gcc to be install alongside your system's current GCC.
You can find all of that information here.
To compile the CUDA 8.0 examples on Ubuntu 16.10, I did:
sudo apt-get install gcc-5 g++-5
cd /path/to/NVIDIA_CUDA-8.0_Samples
# Find the path to the library (this should be in NVIDIA's Makefiles)
LIBLOC=`find /usr/lib -name "libnvcuvid.so.*" | head -n1 | perl -pe 's[/usr/lib/(nvidia-\d+)/.*][$1]'`
# Substitute that path into the makefiles for the hard-coded, incorrect one
find . -name "*.mk" | xargs perl -pi -e "s/nvidia-\d+/$LIBLOC/g"
# Make using the supported compiler
HOST_COMPILER=g++-5 make
This has the advantage of not modifying the whole system or making symlinks to just the binaries (that could cause library linking problems.)
This solved my problem:
sudo rm /usr/local/cuda/bin/gcc
sudo rm /usr/local/cuda/bin/g++
sudo apt install gcc-4.4 g++-4.4
sudo ln -s /usr/bin/gcc-4.4 /usr/local/cuda/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /usr/local/cuda/bin/g++
In my case, I had CUDA already installed from the Ubuntu version and cmake would detect that one instead of the newly installed version using the NVidia SDK Manager.
I ran dpkg -l | grep cuda and could see both versions.
What I had to do is uninstall the old CUDA (version 9.1 in my case) and leave the new version alone (version 10.2). I used the purge command like so:
sudo apt-get purge libcudart9.1 nvidia-cuda-dev nvidia-cuda-doc \
nvidia-cuda-gdb nvidia-cuda-toolkit
Please verify that the package names match the version you want to remove from your installation.
I had to rerun cmake from a blank BUILD directory to redirect all the #include and libraries to the SDK version (since the old paths were baked in the existing build environment).
This is happening because your current CUDA version doesn't support your current GCC version. You need to do the following:
Find the supported GCC version (in my case 5 for CUDA 9)
CUDA 4.1: GCC 4.5
CUDA 5.0: GCC 4.6
CUDA 6.0: GCC 4.7
CUDA 7.0: GCC 4.8
CUDA 7.5: GCC 4.8
CUDA 8: GCC 5.3
CUDA 9: GCC 5.5
CUDA 9.2: GCC 7
CUDA 10.1: GCC 8
Install the supported GCC version
sudo apt-get install gcc-5
sudo apt-get install g++-5
Change the softlinks for GCC in the /usr/bin directory
cd /usr/bin
sudo rm gcc
sudo rm g++
sudo ln -s /usr/bin/gcc-5 gcc
sudo ln -s /usr/bin/g++-5 g++
Change the softlinks for GCC in the /usr/local/cuda-9.0/bin directory
cd /usr/local/cuda-9.0/bin
sudo rm gcc
sudo rm g++
sudo ln -s /usr/bin/gcc-5 gcc
sudo ln -s /usr/bin/g++-5 g++
Add -DCUDA_HOST_COMPILER=/usr/bin/gcc-5 to your setup.py file, used for compilation
if torch.cuda.is_available() and CUDA_HOME is not None:
extension = CUDAExtension
sources += source_cuda
define_macros += [("WITH_CUDA", None)]
extra_compile_args["nvcc"] = [
"-DCUDA_HAS_FP16=1",
"-D__CUDA_NO_HALF_OPERATORS__",
"-D__CUDA_NO_HALF_CONVERSIONS__",
"-D__CUDA_NO_HALF2_OPERATORS__",
"-DCUDA_HOST_COMPILER=/usr/bin/gcc-5"
]
Remove the old build directory
rm -rd build/
Compile again by setting CUDAHOSTCXX=/usr/bin/gcc-5
CUDAHOSTCXX=/usr/bin/gcc-5 python setup.py build develop
Note: If you still get the gcc: error trying to exec 'cc1plus': execvp: no such file or directory error after following these steps, try reinstalling the GCC like this and then compiling again:
sudo apt-get install --reinstall gcc-5
sudo apt-get install --reinstall g++-5
Credits: https://github.com/facebookresearch/maskrcnn-benchmark/issues/25#issuecomment-433382510