I am trying to install lynx / wget on my mac. and installation requires gcc to compile. I have gcc in my /usr/local/bin dir. I see that it is very much there.
spankincubus:Downloads spankincubus$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.0.0/4.6.1/lto- wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.6.1/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.6.1 (GCC)
But when i run a configure utility for wget, i get an error. Any idea?? I'm not a gcc expert for the record.
checking whether make sets $(MAKE)... no
checking build system type... i386-apple-darwin11.4.2
checking host system type... i386-apple-darwin11.4.2
checking for gcc... gcc
checking whether the C compiler works... no
**configure: error: in `/usr/local/bin/wget-1.14':
configure: error: C compiler cannot create executables
See `config.log' for more details**
This is how my gcc looks
-rwxr-xr-x 1 root wheel 91368 Jul 23 2011 gcov
-rwxr-xr-x 1 root wheel 462124 Jul 23 2011 cpp
-rwxr-xr-x 1 root wheel 462060 Jul 23 2011 gcc
Honestly, even though it appears that gcc exists; but does it point to a valid install? It still sounds like it is not installed properly and with an upgrade to Mountain Lion, all your open source tools have been scrubbed away and pushed to Xcode and must be manually installed if necessary.
Related
Mac 10.13.6 High Sierra here. New to C development and I'm trying to get myself setup with the latest stable/recommended GCC version, which I believe (keep me honest here) is 10.2.
When I go to the terminal to see what I have installed:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ gcc -dumpversion
4.2.1
OK...surprised to see LLVM/clang-related stuff in the output. So I try this:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So its almost as if... I have both clang and gcc installed, but my clang installation has assimilated my GCC installation?! Why else would the gcc --version output reference clang?
Is this typical for Mac setups?
What do I need to do to get GCC 10.2 properly installed on my machine?
Here are some simple truths, statements and observations to try and explain what's going on:
Apple ships the clang/LLVM compiler with macOS. Clang is a "front-end" that can parse C, C++ and Objective-C down to something that LLVM (referred to as a "back-end") can compile
Clang/LLVM is located in /Applications/Xcode.app/somewhere
Apple also ships a /usr/bin/gcc which just runs clang. I have no idea why they do that - it doesn't seem very helpful to me - but they don't answer my questions
Apple puts its binaries (programs) in /usr/bin. That is an integral part of macOS and you should never touch or change anything in there - you are asking for problems if you do. This warning applies to Python too.
If you want the real, lovely GNU Compiler Collection (GCC) which includes the gcc, g++ and gfortran compilers, your best bet, IMHO, is to get them from homebrew. I will not put the installation instructions here because they could become outdated, so you should use the ones on the homebrew site.
Once you have homebrew installed, you can install the GNU Compiler Collection (GCC) with:
brew install gcc
After that, you will have all the lovely GNU Compiler Collection (GCC) of tools in /usr/local/bin, so you should put that in your PATH, near the beginning, and in any case before /usr/bin, using:
export PATH=/usr/local/bin:$PATH
In general, you should also add a similar line into your login profile, or into the system login profile, so it is set up every time you or any other user logs in.
Let's take a look:
ls /usr/local/bin/gcc* /usr/local/bin/g++*
/usr/local/bin/gcc-10
/usr/local/bin/g++-10
Depending on the versions and updates, you will then have these programs available:
gcc-10 # the real GNU C compiler
g++-10 # the real GNU C++compiler
gfortran # GNU fortran compiler
And you can check their versions with:
gcc-10 -v
g++-10 -v
gfortran -v
Now you know about homebrew, here are some more simple truths and observations:
folks (who are not the supplier of the operating system) who supply binaries (programs) for you should put their stuff in /usr/local to show that it is just a locally installed program rather than a part of the core macOS operating system
homebrew is well-behaved and installs its binaries (programs) in /usr/local/Cellar and then usually makes symbolic links from /usr/local/bin/PROGRAM to the Cellar. None of this interferes with Apple-supplied stuff.
if you want to run the homebrew version of a command, you should have /usr/local/bin first on your PATH
Let's have a look at those symbolic links:
ls -l /usr/local/bin/g*10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/g++-10 -> ../Cellar/gcc/10.2.0/bin/g++-10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/gcc-10 -> ../Cellar/gcc/10.2.0/bin/gcc-10
If you want to know what you are actually running when you enter a command, use the type command like this.
type gcc
gcc is hashed (/usr/bin/gcc)
That tells you that if you run gcc you will actually be running /usr/bin/gcc which we know is from Apple - because it is in /usr/bin
Now try this:
type gcc-10
gcc-10 is hashed (/usr/local/bin/gcc-10)
That tells you that if you run gcc-10 you will actually be running /usr/local/bin/gcc-10 which we know is from homebrew - because it is in /usr/local/bin
I have code that depends on <X11/Xlocale.h>. When I try to compile with the emscripten tool chain (after CMake generate), I get the following error. What do I need to change in my configuration?
'X11/Xlocale.h' file not found
# include <X11/Xlocale.h>
^~~~~~~~~~~~~~~
1 error generated.
I'm doing this on Linux.
$ uname -a
Linux bracket 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I've confirmed I have libx-dev installed.
$ sudo apt-get install libx11-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libx11-dev is already the newest version (2:1.6.4-3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Emscripten can't use native libraries -- it's outputting Javascript code, after all; it can't use libraries which contain native x86 (or other architecture) code. As such, emscripten won't search for headers in your system's include directories, because a lot of those headers will describe functionality which isn't available to an Emscripten program. It uses internal search paths instead.
Now, <X11/Xlocale.h> is a bit of a weird header. It doesn't actually define anything; it just includes <locale.h>, so you may be able to get away with replacing #include <X11/Xlocale.h> with #include <locale.h>. However, if your application uses other X11 functionality, it may not be buildable under Emscripten.
I'm doing a crossbuild of a QT app from a Debian (Stretch) PC to a Debian (Jessie) BeagleBone Black, and when I executed this, I got the message
/home/bbuser/totemguard/totemguard: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/bbuser/totemguard/totemguard)
I saw that the armhf g++ version was 6.1 so I install the 4.9.2-10 (the same that I had on the BeagleBone Black) and recompiled my code, with similar result (different GLIBXX version):
/home/bbuser/totemguard/totemguard: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/bbuser/totemguard/totemguard)
Reading the ABI Policy and Guidelines, the G++ version for GLIBCXX_3.4.21 is 5.1.0:
GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8
GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9
GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10
But I never had the 5.1 version installed on my host PC or BeagleBone Black board.
Listing the /usr/lib/arm-linux-gnueabihf/ directory we can see that there are only the GCC 4.9.0 and GCC 6.1.0 libstdc++ version:
lrwxrwxrwx 1 root root 19 ago 3 15:53 libstdc++.so.6 -> libstdc++.so.6.0.22
-rw-r--r-- 1 root root 658064 dic 27 2014 libstdc++.so.6.0.20
-rw-r--r-- 1 root root 1019632 ago 3 15:53 libstdc++.so.6.0.22
This problem begin after a distro-upgrade from jessie to stretch, and I can't upgrade the beaglebone black gcc version.
What can I do?
EDIT 1:
On a test board (BeagleBone Black) I added the stretch repository and did this:
bbuser#beaglebone:~/totemguard$ sudo apt-cache policy libstdc++6
libstdc++6:
Installed: 4.9.2-10
Candidate: 6.1.1-11
Version table:
6.1.1-11 0
500 http://ftp.us.debian.org/debian/ stretch/main armhf Packages
*** 4.9.2-10 0
500 http://ftp.us.debian.org/debian/ jessie/main armhf Packages
100 /var/lib/dpkg/status
bbuser#beaglebone:~/totemguard$ sudo apt-get install libstdc++6
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
gcc-6-base
The following NEW packages will be installed:
gcc-6-base
The following packages will be upgraded:
libstdc++6
1 upgraded, 1 newly installed, 0 to remove and 726 not upgraded.
Need to get 517 kB of archives.
...
And the application ran fine (not 100% tested, but give no errors). Still this is a test board and I cant do the same on a production board.
solution 1) use -static (full libraries) or compile-in only libstdc++ as static to the binary
solution 2) distribute the appropriate libstdc++ version with the binary (possibly using LD_PRELOAD)
solution 3) use exactly the same g++ libstdc++ version for crosscompiling (at least matching)
usually better is to use solution 1) - you will have no problems across distros upgrade
This has been plaguing me for awhile now. I am trying to compile a huge C++ file (I know it works as I it works fine on my Arch Linux computer at work). When I checked my GCC version on my mac It returns the following
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I have also installed the most recent GCC version using Homebrew with
brew install gcc49
My question now is how do I apply that newly installed GCC version to be the default version that the terminal uses?
I am also aware that when you use homebrew to isntall gcc it names it gcc-49 so that there is no confusion between packages.
I have no idea how to replace the 4.2.1 version that comes with XCode with the 4.9 version I have installed.
Thanks
Edit:
Switched to my mac to get the full return statement of gcc --version
Edit 2:
My end game here is to be able to navigate to the directory and be able to type
make
sudo make install
to install the daemon that has been made. Right now that returns tons of errors with random packages and the Standard Library
By default, homebrew places the executables (binaries) for the packages it installs into /usr/local/bin - which is a pretty sensible place for binaries installed by local users when you think about it - compared to /bin which houses standardisded binaries belonging to the core OS. So, your brew command should have installed gcc-4.9 into /usr/local/bin. The question is now how to use it... you have several options.
Option 1
If you just want to compile one or two things today and tomorrow, and then probably not use the compiler again, you may as well just invoke the gcc installed by homebrew with the full path like this:
/usr/local/bin/gcc-4.9 --version
Option 2
If you are going to be using gcc quite a lot, it gets a bit tiresome explicitly typing the full path every time, so you could put the following into your ~/.bash_profile
export PATH=/usr/local/bin:$PATH
and then start a new Terminal and it will know it needs to look in /usr/local/bin, so you will be able to get away with simply typing
gcc-4.9 --version
Option 3
If you just want to use gcc to invoke the compiler, without worrying about the actual version, you can do Option 2 above and additionally create a symbolic link like this
cd /usr/local/bin
ln -s gcc-4.9 gcc
That will allow you to run the homebrew-installed gcc by simply typing gcc at the command line, like this
gcc --version
Note:
If you later want to install, say gcc-4.13 or somesuch, you would do your brew install as before, then change the symbolic link like this:
cd /usr/local/bin
rm gcc # remove old link from gcc to gcc-4.9
ln -s gcc-4.13 gcc # make new link from gcc to gcc-4.13
Note that if you are actually using C++ rather than C, you will need to adapt the above for g++ in place of gcc.
simply updating the order of $PATH in ~/.bash_profile to the brew installed version 'export PATH=/usr/local/Cellar/gcc/5.1.0/bin:$PATH' was not enough to make the switch for me
changing the alias in your ~./bash_profile (alias gcc='gcc-5') works, but can be confusing i.e. which gcc will return the Clang version
what worked for me was to make a symbolic link in the brew gcc directory as well as update the path (point 1 above)
cd /usr/local/Cellar/gcc/5.1.0/bin/gcc
ln -s gcc-5 gcc
now which gcc returns the correct version 5.1.0
OS X does not come with GCC installed (4.2.1 or otherwise). Clang is the default system compiler and has been for some time. It is using the C++ headers from 4.2.1 when invoked as GCC. Have you tried compiling your code with Clang natively, instead of calling "gcc" (which calls Clang)? It has more modern headers and C++ support than the GCC emulation mode.
Download the gcc binaries untar and copy the bin, lib include share and libexec files to your /usr directory then type gcc --version this is what i expect you to see
gcc --version
gcc (GCC) 4.9.2 20141029 (prerelease)
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.
I have installed 4.7 version of c++ which does not support c++11. So I followed This and installed new version which also 4.7. Now I am confused how I switch newely installed g++.
When I enter ls -lh /usr/bin/g++* I get this:
lrwxrwxrwx 1 root root 21 Aug 23 08:54 /usr/bin/g++ -> /etc/alternatives/g++
-rwxr-xr-x 1 root root 516K Apr 15 17:42 /usr/bin/g++-4.7
Both are same but How can I switch to newer?
gcc 4.7 does support C++11, if you run it with the -std=c++11 option. Have you tried that?
There is no way your package installer would have let you have two separate installations of g++ 4.7. The page you linked states that you'd end up with both 4.6 and 4.7, not two versions 4.7.
If you had different g++ version, you could select which one gets used by the g++ command using update-alternatives --config g++, however running g++-4.7 will always get you the 4.7 version.
Also note that 4.7 does support some C++11 features (use -std=c++11), but not all of them. This page lists the status of the implementation.