Linking Homebrew-compiled openmpi (or mpich2) to Homebrew's gcc - c

I'm new to Homebrew (I usually use Macports, but I'm trying out Homebrew on a 2nd computer), and I wish to install the openmpi (or mpich2) package. Steps are as follows (carried out on Mac OS X Yosemite with Xcode 6 installed):
brew install gcc
brew install openmpi
However, I suspect the linking may have been done incorrectly, due to the following reasons:
The symbolic link for /usr/local/bin/gcc is missing:
$ which gcc
/usr/bin/gcc
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
$ which gcc-4.9
/usr/local/bin/gcc-4.9
$ gcc-4.9 --version
gcc-4.9 (Homebrew gcc 4.9.2) 4.9.2
Copyright (C) 2014 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.
mpicc may have been linked to the Apple gcc:
$ which mpicc
/usr/local/bin/mpicc
$ mpicc --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
My questions are as follows:
How do I get the /usr/local/bin/gcc symbolic link? Or is Homebrew deliberately avoiding this for certain reasons? e.g. if Homebrew is compiling all its packages using Apple gcc, which is assumed to be in the path, would changing the path to gcc-4.9 mean that Homebrew now compiles its packages with gcc-4.9 instead?
Is the Homebrew-installed Open MPI linked to the Apple gcc (and not the Homebrew gcc)? If yes, is it possible (or advisable) to change the linking?
Alternatively, how necessary is it to fix the linkages? Could I run into certain problems if I choose not to fix it? For example, I'm considering using ln -s to forcibly create the /usr/local/bin/gcc symbolic link. But is this a good idea (*)?
(*) I understand there are likely to be issues when linking object files created by different compilers. So with (1), (2) and (3), I'm hoping to find a solution that avoids combinations whereby I'm creating object files with different compilers (some with gcc-4.9 and some with the Apple gcc).

You need to do the following:
1) Add environment variables for homebrew (you can also add these lines to your ~\.bashrc):
$ export HOMEBREW_CC=gcc-4.9
$ export HOMEBREW_CXX=g++-4.9
2) Rebuild and reinstall openmpi and its dependencies from source
$ brew reinstall openmpi --build-from-source
3) In the end you will get a message like:
==> Reinstalling open-mpi
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.
==> Downloading http://www.open-mpi.org/software/ompi/v1.8/downloads/openmpi-1.8.
Already downloaded: /Library/Caches/Homebrew/open-mpi-1.8.4.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/open-mpi/1.8.4 --disable-silent-rules
==> make all
==> make check
==> make install
Warning: open-mpi dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.
🍺 /usr/local/Cellar/open-mpi/1.8.4: 785 files, 23M, built in 41.2 minutes
$ mpicc --showme
gcc-4.9 -I/usr/local/Cellar/open-mpi/1.8.4/include -L/usr/local/opt/libevent/lib -L/usr/local/Cellar/open-mpi/1.8.4/lib -lmpi
On my MacBook I had some conflicts with XCode 6.2, which were solved following this instructions
If you want to install mpich
$ unlink openmpi
$ brew unlink gcc
$ brew install homebrew/versions/gcc5
$ brew install mpich --build-from-source
$ mpicc -v
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc5/5.4.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.4.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0 --prefix=/usr/local/Cellar/gcc5/5.4.0 --libdir=/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl014 --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc5 5.4.0' --with-bugurl=https://github.com/Homebrew/homebrew-versions/issues --enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 5.4.0 (Homebrew gcc5 5.4.0)

It would probably be cleaner if you simply modify the configuration file for the Open MPI compiler wrapper and make it invoke gcc-4.9 instead of simply gcc. As I have no idea where exactly Homebrew puts Open MPI and therefore cannot give you the correct path directly, you should search for it:
$ find /usr/local -name mpicc-wrapper-data.txt
Once you have found mpicc-wrapper-data.txt, find the line that starts with compiler= and modify it to read:
compiler=gcc-4.9
You should also modify all other files that match the shell glob mpi*-wrapper-data.txt and modify the compiler=... line accordingly. Use g++-4.9 in mpic++, mpicxx, and mpiCC. Use gfortran-4.9 (if installed) in mpif77 and mpif90 (for Open MPI versions < 1.8) or for mpifort (for versions >= 1.8).
Mixing object code produced by different compilers on the same platform should be fine as long as all of them adhere to the same ABI, which is more or less the case with Clang and GCC. In the end, all programs are linked against the system libraries that come with OS X and those are compiled with Clang only.

Related

MIPS GCC cross-compiler build fails: "cannot find -lc"

I am trying to set up a GCC 4.9.4 cross-compiler for a QCA955X-based router with Linux 2.6.31. This is a MIPS32R2-abi CPU that uses uClibc-0.9.30.1 (as found in /lib.) Due to this, I have decided to compile a GCC 4.x with the matching uClibc and binutils-2.19.1a. My host system is Ubuntu 18.04 with Linux 4.17-rc5 and gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
~/mips-cross-gcc/staging_dir is my prefix, and ~/mips-cross-gcc/staging_dir/sysroot is the makeshift sysroot for my system.
1) I downloaded binutils-2.19.1a.tar.bz2, gcc-4.9.4.tar.bz2, linux-2.6.31.9.tar.xz, and uClibc-0.9.30.1.tar.bz2 into ~/mips-cross-gcc/sources.
2) I untar'd all the sources.
3) Install linux headers:
make ARCH=mips INSTALL_HDR_PATH=/home/user/mips-cross-gcc/staging_dir/sysroot/usr headers_install
4) Build binutils:
cd binutils-2.19.1
./configure --prefix=/home/user/mips-cross-gcc/staging_dir --target=mips-linux-uclibc --disable-multilib --disable-werror --enable-shared --without-newlib --with-sysroot=/home/user/mips-cross-gcc/staging_dir/sysroot --enable-languages=c,c++ --disable-libgomp
make all-binutils
make all-ld
make all-gas
make install-binutils
make install-ld
make install-gas
5) Build "stage 1" gcc, to bootstrap uClibc:
cd gcc-4.9.4
mkdir -p build/gcc-stage1
../../configure --target=mips-linux-uclibc --prefix=/home/user/mips-cross-gcc/staging_dir --disable-werror --disable-libgomp --without-newlib --disable-multilib --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --disable-nls --disable-libmudflap --disable-libssp --with-float=soft --with-sysroot=/home/user/mips-cross-gcc/staging_dir/sysroot --with-gnu-ld --without-headers
make all-gcc
make install-gcc
6) Install uClibc headers:
cd uClibc-0.9.30.1
make PREFIX=/home/user/mips-cross-gcc/staging_dir/sysroot install_headers
7) Build libgcc for target arch:
cd gcc-4.9.4
make all-target-libgcc
Libgcc is compiled all the way until the final libgcc_s linking stage:
/home/daniel/mips-cross-gcc/staging_dir/mips-linux-uclibc/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
Makefile:937: recipe for target 'libgcc_s.so' failed
I thought that bootstrapping a GCC would not require a libc, because it has not been compiled yet, right? What could I be doing wrong? I would use this compiled GCC to build uClibc, and then I would compile GCC again with my new uClibc so that I can cross-compile software. The fact that GCC requires libc in the first build seems wrong.
I tried to use the first gcc without compiling libgcc for building uClibc, but nearly instantly I received:
LD ld-uClibc-0.9.30.1.so
mips-linux-uclibc-gcc: error: libgcc.a: No such file or directory
ldso/ldso/Makefile.in:54: recipe for target 'lib/ld-uClibc.so' failed
So, uClibc needs libgcc to link itself, and gcc needs a libc (of any type, including uClibc) to link its own libgcc. This seems like a chicken-and-egg problem. How would one fix this?
I fixed it. Apparently, GCC has to be built without shared libraries enabled (--disable-shared) so that it doesn't link the generated libraries like libgcc dynamically (i.e to libc,) but that still didn't work. -lc was still not found.
I did some more googling, and I found this helpful message from eglibc, about making their own toolchain with gcc: eglibc.org
The First GCC
For our work, we need a cross-compiler targeting a PowerPC Linux
system. However, that configuration includes the shared library
'libgcc_s.so', which is compiled against the EGLIBC headers (which we
haven't installed yet) and linked against 'libc.so' (which we haven't
built yet).
Fortunately, there are configuration options for GCC which tell it not
to build 'libgcc_s.so'. The '--without-headers' option is supposed to
take care of this, but its implementation is incomplete, so you must
also configure with the '--with-newlib' option. While '--with-newlib'
appears to mean "Use the Newlib C library", its effect is to tell the
GCC build machinery, "Don't assume there is a C library available."
Looks like with enough digging, someone's bound to find the exact problem one has.
In short, changing --enable-shared to --disable-shared and adding --with-newlib to GCC's
./configure solved the issue and compiled + linked a libgcc_s.so that I used to compile uClibc, and then recompiled gcc with the newly generated libc, from uClibc. Indeed, it is possible to compile a 2016 GCC 4.x with a 2011 uClibc on a 2018 GCC 7.x.

How can I install gcc 4.2.1 on OSX Sierra?

I'm using the Bochs emulator and for my class we're using gcc 4.2.1. I believe I've gotten Bochs running, but now I need to compile our programs which are compatible with gcc 4.2/.1.
I understand OSX uses an alias for gcc 4.2.1, but how can I use gcc specifically and not clang?
Edit: GCC 4.6.3 not 4.2.1 sorry
You can install previous version of gcc pretty easily using homebrew.
If you have homebrew installed you can get gcc 4.9 by running
brew install gcc#4.9
After it is installed gcc will still map to the clang that came with your mac. The newly installed gcc will be installed at /usr/local/bin and be called something like gcc-4.
You can find the exact executable name using
ls /usr/local/bin | grep gcc
Hopefully 4.9 is close enough to 4.6 for your purposes.

Install GCC on Mac OS high sierra

I've already visited the following answer but my question is different.
Install GNU GCC on mac
Mac OS ships with Clang and somehow /usr/bin/gcc is linked to Clang tool I assume because of this line.
gcc
clang: error: no input files
Any idea on how can I install https://gcc.gnu.org/ standalone on my system?
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin17.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Any idea on how can I install https://gcc.gnu.org/ standalone on my system?
Generally speaking: Don't. That isn't a standard configuration; Clang is the recommended compiler for current macOS systems.
If you have a very good reason, you can use Homebrew to install GCC (brew install gcc). Keep in mind that it cannot be used to build native macOS applications.

linking clang address sanitizer on FreeBSD 10.1 Release

I'm trying to get address sanitizer working on FreeBSD 10.1 Release, but whenever I try to compile a program with -fsanitize=address I get undefined references to _asan_stack_malloc_1 etc, etc. I found
https://forums.freebsd.org/threads/gcc-clang-address-sanitizer.47985/ on google but the suggestion of adding -L/usr/local/lib -I/usr/local/include didn't resolve the linking issue. I tried the llvm binaries for FreeBSD but when I go to compile with that clang I get /usr/bin/../lib/clang/3.6.0/lib/freebsd/libclang_rt.asan-x86_64.a , no such file or directory. . Either way I'm not sure what library I need to link or where it is.
Below is the program I tried compiling and here is the command I used,
clang -fsanitize=address san.c
#include <stdio.h>
int main(void)
{
return 0;
}
As an alternative to building LLVM, as suggested in this answer on Unix SE, you can install llvm37 from ports, which supports AddressSanitizer, and build with that:
# pkg install llvm37
$ clang37 -fsanitize=address san.c
To use asan on FreeBSD you can build llvm with asan support as shown below or you can install from packages/ports like in Kevinoid's answer.
Step one, grab the latest stable llvm source.
fetch http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz
Now uncompress the llvm source directory.
tar -xvf llvm-3.9.0.src.tar.xz
Next change directory to llvm and grab the clang source files.
cd llvm-3.9.0.src/tools && fetch http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz
Uncompress clang.
tar -xvf cfe-3.9.0.src.tar.xz
Enter the projects directory and grab compiler-rt.
cd ../projects && fetch http://llvm.org/releases/3.9.0/compiler-rt-3.9.0.src.tar.xz
Uncompress compiler-rt.
tar -xvf compiler-rt-3.9.0.src.tar.xz
Goto the root llvm directory and make a build directory for cmake.
cd ../ && mkdir build && cd build
Use cmake to setup the llvm build.
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON [-DLLVM_ENABLE_WERROR=ON] [-DLLVM_TARGETS_TO_BUILD=X86] -DBUILD_SHARED_LIBS=ON ../
Build llvm and go grab some tea, it will take a bit.
make -j12
If the build worked you should be left with clang with asan support. Make sure to remove the old compiler, /usr/bin/clang, /usr/bin/clang++ and /usr/bin/cc.
Then install the new clang by doing sudo make install. Finally you will probably want to link /usr/bin/cc to /usr/local/bin/clang by running sudo ln /usr/local/bin/clang /usr/bin/cc.
After doing all these steps you should be able to compile code with the -fsanitize=address compile option.

how to find gcc version on mac

I am using OS 10.9 on mac machine. I want to know the version of gcc I am using. So I tried gcc --version on terminal and it results :
$ gcc --version
Configured with: --prefix=/Applications/Xcode5-DP.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode5-DP.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.1.58) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Here in output, there is no detail related to gcc but clang is there. I am confused
whether gcc command executes clang or gcc(gnu).
You seem to not actually have gcc on your path. As of recent versions of Xcode, it installs a "gcc" that is instead a link to Clang.
gcc -dumpversion | cut -f1 -d.
-dumpversion Print the compiler version (for example, 3.0) — and don't do anything else.
The same works for following compilers/aliases:
cc -dumpversion
g++ -dumpversion
clang -dumpversion
tcc -dumpversion
Be careful with automate parsing the GCC output:
Output of --version might be localized (e.g. to Russian, Chinese, etc.)
GCC might be built with option --with-gcc-major-version-only. And some distros (e.g. Fedora) are already using that
GCC might be built with option --with-pkgversion. And --version output will contain something like Android (5220042 based on r346389c) clang version 8.0.7 (it's real version string)
The tools supplied by Apple have been switched from GCC to Clang. The gcc command is linked to clang as a convenience. In OS X 10.9, you do not have GCC on your system unless you have installed it independently of Apple packages.
In case you installed gcc via brew install, it might've got installed as gcc-11.
You can run brew info gcc to get path where it is installed and get exact name of the binary by listing the directory.
$ brew info gcc
gcc: stable 11.2.0 (bottled), HEAD
GNU compiler collection
https://gcc.gnu.org/
/usr/local/Cellar/gcc/11.2.0_3 (2,163 files, 459.8MB) *
...
$ ls /usr/local/Cellar/gcc/11.2.0_3/bin
c++-11 gcc-ar-11 gcov-dump-11 gfortran x86_64-apple-darwin21-g++-11 x86_64-apple-darwin21-gcc-ranlib-11
cpp-11 gcc-nm-11 gcov-tool-11 gfortran-11 x86_64-apple-darwin21-gcc-11 x86_64-apple-darwin21-gcc-tmp
g++-11 gcc-ranlib-11 gdc lto-dump-11 x86_64-apple-darwin21-gcc-ar-11 x86_64-apple-darwin21-gdc-11
gcc-11 gcov-11 gdc-11 x86_64-apple-darwin21-c++-11 x86_64-apple-darwin21-gcc-nm-11 x86_64-apple-darwin21-gfortran-11
Then using gcc-11 -v will get you actual version of gcc installed.
$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0_3/bin/../libexec/gcc/x86_64-apple-darwin21/11/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: ../configure --prefix=/usr/local/opt/gcc --libdir=/usr/local/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin21 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0_3)
gcc -dumpversion | cut -f1 -f2 -f3 -d.

Resources