I've recently installed gcc 4.6.3 on my MAC (with OSX Lion, XCode 4.3, gcc 4.2.1). I've made a folder named my_gcc463, which contains all files after compiling gcc with make command, etc.
I've also installed MacPorts to select between all versions of gcc that I have. The problem is when I run this command:
port select --list gcc
I can't see the new gcc 4.6.3 in the list so that I can select that. Also when I run this command:
sudo ln -s -f ~/my_gcc463/gcc-4.6.3 /usr/bin/gcc
to link gcc to the one I want, It's not working. For example after creating that symlink, when I run:
gcc -v
It doesn't give me the version. What should I do to make my new gcc appear in the gcc list? Did I do anything wrong? Should I install it in other way?
Thank you in advance for helping me. :)
port select is a tool to maintain the gcc installations from MacPorts and, if available, the versions provided by Apple. Although you could hack it up by dropping your own descriptions into /opt/local/etc/select/gcc, I would recommend a different approach for this.
To achieve what you want you should modify your PATH environment variable to include the new path to your gcc version at the front, such that gcc resolved to the correct absolute path.
Assuming your new gcc binary is at ~/my_gcc463/gcc, you should add the following to your .profile/.bash_profile or .bashrc:
export PATH=~/my_gcc463:$PATH
After setting this up, run gcc -v in a new terminal window to check if it is working as expected.
Related
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.
I somehow lost the man pages for gcc and g++. I'm not sure where/what to look for. I'm pretty sure the man pages used to work some time ago. It also works on my Mac at work where I use roughly the same setup. Could it be a problem with brew? Or is it a bug in the XCode Command Line Tools?
Update: I just tried to re-install the XCode Command Line Tools. No luck.
~
✓ man gcc
No manual entry for gcc
~
✗ which gcc
/usr/bin/gcc
~
✓ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
gcc isn't installed anymore by Xcode, it really installs clang and calls it gcc
usxxplayegm1:~ grady$ which gcc
/usr/bin/gcc
usxxplayegm1:~ grady$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix
you need man clang
I thought it was a symlink, but ls -l doesn't list it as a symlink, so either it is a hard link or some other sort of trickery.
This may be old and doesn't quite answers your concrete question, but I found myself in the same problem with Kali Linux and I solved it with this command, maybe is useful for someone:
apt install gcc-doc
Look at how you set MANPATH in your .profile. Instead of, e.g.,
export MANPATH=/opt/local/man:/usr/local/man
you should do
export MANPATH="/opt/local/man:/usr/local/man:$MANPATH"
And then (breathe) open a new Terminal window.
This way your .profile isn't wiping out (or reflecting an old version of) the system's way of setting MANPATH, which is modified when you install (or reinstall) Xcode.
I use High Sierra with g++ 7.2 port. Setting MANPATH environment to /opt/local/man (or to /opt/local/man/man1 where g++.gz is found) did not work. So, after ensuring that the soft link g++.gz points to g++-mp-7.1.gz (there was not a g++-mp-7.2.gz in the man1 directory though g++7.2 is my version), I always use the command:
man /opt/local/share/man/man1/g++.gz
that never fails. You can store an alias for this in your .profile, if you are frequently using the man command for g++.
For anyone who stumbles upon this currently (like I did), I found that I needed to locate my version of gcc (which I had installed with brew). This is annoying when gcc --version gives the clang version instead! To find the correct gcc version, run
$ ls /usr/local/opt/gcc/bin | grep gcc
gcc-10
gcc-ar-10
gcc-nm-10
...
So I had gcc-10. Whenever you wish to use gcc just replace it with gcc-10, e.g. man gcc-10. Of course you could write an alias for gcc to gcc-10, but this probably is not a great idea, as Xcode seems to rely on the gcc --> clang (hard?) link.
On Mac OSX 10.9, the default c compiler bundled with Xcode is clang. I installed gcc-4.9 with homebrew. Now I have two different gccs, one is clang, the other is gcc. The default is clang.
I want to use gcc when compiling Haskell files with ghc, and I want also gcc when I launch ghci. How to do this change?
Reproducing my directions I've been sharing with haskellers for the past few months via https://gist.github.com/cartazio/7131371
Type ghc --print-libdir
The output will be a path like /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3
Go to that directory and edit the settings file.
There'll be a line indicating the path to the C compiler. It'll probably say /bin/gcc
Change that line to /usr/local/bin/gcc-4.8 (or whichever gcc version you brew installed, such as /usr/local/bin/gcc-4.2)
According to this post (https://github.com/mxcl/homebrew/pull/2953), the flag "--with-mpi" should enable boost_mpi build support for the related homebrew formula, so I am trying to install boost via homebrew like this:
brew install boost --with-mpi
However, the actual boost mpi library is not being build and can not be found.
There is currently some work being done around this, according to: https://github.com/mxcl/homebrew/pull/15689
In summary, I can currently build boost, but it seems the "--with-mpi" flag is being ignored. Could someone please check, if I should be able to build boost (with mpi support) on Mac OS X Mountain Lion (10.8)?
The (verbose) output generates these lines:
MPI auto-detection failed: unknown wrapper compiler mpic++
Please report this error to the Boost mailing list: http://www.boost.org
You will need to manually configure MPI support.
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
Not sure how exactly I can fix this and get the mpi stuff to be build - any ideas?
Just in case this helps anyone else along the line, here's how I fixed this. The main error is MPI auto-detection failed: unknown wrapper compiler mpic++, any typing mpic++ at the command line verified that it was not working properly for me. I used brew to install open-mpi, but the same error was showing in the verbose output for installing boost. A run of brew doctor showed that openmpi was not linked properly, so I fixed those errors and reran brew -v install boost --with-mpi --without-single and it finally built and installed all of the libraries without a problem
To anyone that comes across this, the package migrated to boost-python and boost-mpi separate from boost. Use brew install boost-mpi
Just get it worked on OSX 10.11.5. I've tried brew, but with no luck.
Suppose you already have gcc installed. Here are what I've done:
1. Find and disable (but do not remove) clang
clang alway cause headaches. There would be a lot of warnings when building Boost.
which clang, which should give you /usr/bin/clang
Rename it: sudo mv clang clang_mac_remove, also for clang++: sudo mv clang++ clang++_mac_remove. You can change the names back if you need them in future.
2. Install OpenMPI
If you already installed using brew, uninstall first. Becasue it would have used clang as the compiler wrapper by default. You need to change the wrapper to gcc.
Download the package.
Specify the wrapper compiler to gcc and g++:
./configure CC=gcc CXX=g++ F77=ifort FC=ifort --prefix=/usr/local
Below may take a long time.
make all
sudo make install
Reference: https://wiki.helsinki.fi/display/HUGG/Open+MPI+install+on+Mac+OS+X
3. Install Boost MPI
Download the package.
Run ./bootstrap.sh (can open it first and specify the toolset to gcc, otherwise, the default option is darwin for mac).
Add using mpi ; in project-config.jam file. Then ./b2 —with-mpi will only build the mpi library.
Then, all built libraries can be found in the folder ~/Downloads/boost_1_61_0/stage/lib.
Copy or move them to /usr/local/lib or any other commonly used library path.
Reference: http://www.boost.org/doc/libs/1_61_0/doc/html/mpi/getting_started.html
4. Compile with Boost MPI
LIBRARY DIR = -L/usr/local/lib
INCLUDE = -I/usr/local/include/
LINKER = -lboost_mpi -lboost_serialization
e.g.
mpic++ -std=c++11 -I/usr/local/include/ -c boost_test.cpp -L/usr/local/lib -lboost_mpi -lboost_serialization
Good luck!
I have a problem concerning libstdc++.so.
I installed a new version of gcc and tried to compile C++ code. The compiling worked, but when I try to execute the binary (m5.opt is its name) I've got the following error:
build/ALPHA_SE/m5.opt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by build/ALPHA_SE/m5.opt).
Do I need to replace libstdc++.so? And if so, where can I download the version I want? On the GCC-website they say libstdc++ is a part of gcc now.
Details
GCC:
I had gcc 4.1.2 before, but I downloaded gcc 4.2.4. From the untarred gcc-directory I executed ./configure; make; sudo make install`.
When I tried to use gcc or g++ to compile, it's default version was still 4.1.2. To overcome this I replaced some links:
mv /usr/bin/gcc /usr/bin/gcc_bak
ln -s /usr/local/bin/gcc gcc
mv /usr/bin/g++ /usr/bin/g++_bak
ln -s /usr/local/bin/g++ g++
GLIBC(++) -- libstdc++:
/usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8
/usr/local/lib/libstdc++.so -> libstdc++.so.6.0.9
/lib/libc.so.6 -> libc-2.5.so -> libc-2.5.so
Linux-version:
uname -a gives:
Linux madmax 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 12:51:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
The problem is that you built your new GCC incorrectly: on Linux you should use
./configure --prefix=/usr
The default installation prefix is /usr/local, which is why make install put gcc and g++ binaries into /usr/local/bin, etc.
What's happening to you now is that you compile and link using the new (symlinked) GCC 4.2.4, but at runtime your program binds to the old /usr/lib64/libstdc++.so.6 (version 6.0.8, instead of required 6.0.9). You can confirm that by running ldd build/ALPHA_SE/m5.opt: you should see that it uses /usr/lib64/libstdc++.so.6.
There are several fixes you could do.
env LD_LIBRARY_PATH=/usr/local/lib64 ldd build/ALPHA_SE/m5.opt
should show you that setting LD_LIBRARY_PATH is sufficient to redirect the binary to correct library, and
LD_LIBRARY_PATH=/usr/local/lib64 build/ALPHA_SE/m5.opt
should just run. You could "bake" this path into m5.opt binary by relinking it with -Wl,-rpath=/usr/local/lib64.
A more permanent solution is to fix the libraries the same way you fixed the binaries:
cd /usr/lib64 && mv libstdc++.so.6 libstdc++.so.6_bak &&
ln -s /usr/local/lib64/libstdc++.so.6 .
An even better solution is to reconfigure the new GCC with --prefix=/usr, and then make all install.
I know this is a very old question, but ...
It's not usually a good idea to replace the system compiler (i.e. the one in /usr) because the entire system will have been built with it and depend on it.
It's usually better to install the new compiler to a separate location and then see the libstdc++ FAQ How do I insure that the dynamically linked library will be found? and Finding Dynamic or Shared Libraries in the manual for how to ensure the correct libstdc++.so is found at runtime.
The other answers here should be fine, but the 'quick and easy' solution if you do happen to have gcc installed to /usr/local/ is to just add the new libs to the LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
You can also check the to see if you have the right versions of GLIBC installed using
strings /usr/lib/libstdc++.so.6 | grep GLIBC
strings /usr/local/lib64/libstdc++.so.18 | grep GLIBC
I got this last tip from another forum so credits due where credits due!