In OS X, how can I link gcc-4.8 from homebrew to gcc? I already tried to link gcc-4.8 to /usr/local/bin/gcc but this does not work. I really need this because I have shared makefiles in a course at the university.
There are at least a couple of options.
I have my GCC 4.8.2 installed under /usr/gcc/v4.8.2 and I ensure that /usr/gcc/v4.8.2/bin is on my PATH ahead of /usr/bin. That way, the undecorated name gcc means GCC 4.8.2. (This is on Mac OS X 10.9.1 Mavericks, just for the record.)
Specify CC=/usr/gcc/v4.8.2/bin/gcc on command lines, etc. Painful, so I don't regard it as a real option.
Make /usr/bin/gcc point to /usr/gcc/v4.8.2/bin/gcc instead of being an executable that runs clang.
I distrust modifying /usr/bin or /bin (or /sbin or /usr/sbin). I seldom use the system-provided Perl, for example, but always use my own build, using the same general technique.
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.
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)
I have Lion 10.7.3 with the Command-line tool installed. I wanted to experiment with C++11, so I used homebrew to install GCC 4.7 as documented here.
How can I now upgrade the /usr/bin/g++ to be the one installed by Homebrew? Is it as simple as symlinking it? I just want to double check and make sure. Thanks!
First, are you sure you need g++ 4.7? As you can see from the C++11 implementation status page, recent versions of clang support most of C++11 too. Of course there are still things that g++ handles and clang doesn't, but there are also still things that clang supports and g++ doesn't. And, more importantly, you already have a recent version of clang, from Apple, configured and ready to go, as your default compiler. Plus, g++ after 4.2 doesn't support Mac extensions like, say, -arch, which means you can't use it to build a whole lot of third-party software (because most configure scripts assume that if you're on a Mac, your compiler supports Mac extensions).
But if you want g++ 4.7, you can do it. Just not by trying to replace /usr/bin/g++ with a different version. Never replace anything in /usr/bin (or /System) with non-Apple stuff except in a few very rare cases (when you have a strong reassurance from someone who knows what they're talking about).
A better thing to do is to just install another compiler in parallel. Just let Homebrew install its favorite way (so it installs into some prefix like /usr/local/Cellar/gcc/4.7, then symlinks all the appropriate stuff into /usr/local/bin, etc.), and use it that way.
When compiling your code, instead of writing g++, write /usr/local/bin/g++, or g++-4.7.
If you get tired of doing that, put /usr/local/bin higher on your PATH that /usr/bin, or create a shell alias, or stick it in the environment variable CXX and write $CXX instead of g++.
If you're using a GUI IDE, you should be able to configure it to use your compiler by setting the path to it somewhere. (Unless you're using Xcode, which you can only configure to work with Apple-tested compilers.)
This is all you need for experimenting with your own code. If you want to compile third-party applications with this compiler, that may be a bit more complicated. You don't often actually compile each source file and link the result together; you just do configure && make and let them do the heavy lifting for you.
Fortunately, most packages will respect the standard environment variables, especially CXX for specifying a default C++ compiler and CC for a default C compiler. (That's why I suggested the name CXX above.)
Just remember that, again, g++ 4.7 doesn't support Mac extensions, so if you're not prepared to debug a bunch of autoconf-based configure scripts complaining that your compiler can't generate code because it assumed it could throw -arch x86_64 at any compiler on a Mac, etc., don't do this.
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.
I'm having a lot of trouble compiling the otherwise excellent Contiki OS on my macbook pro (with mac os x 10.6). Contiki actually uses a lot of GNU-specific features and options of GCC, AR, LD, and so on. So I installed those utilities via macports, but it looks like "port install binutils" does not install GNU ld, does it ?
So, the question is, how do I get GNU ld on my mac ? Is there a simple alternative to the hard-way (i.e. the wget, configure, make, make install way) ?
As far as I can tell, GNU binutils does not support the Mach-O format. None of the documentation mentions it, and some Googling turns up some recent messages indicating that it is not supported.
Now, you mention the Contiki OS, which looks to me like an embedded operating system. Are you needing to compile to a native executable, or are you trying to cross-compile for some other environment? MacPorts does include several ports of binutils for cross compilation.
$ port info binutils
(…) Tools are prefixed with g to avoid conflicts with original tools. (…)