I am on a Mac. I updated my OSx to Yosemite. I updated my xcode to version 6. I downloaded the command line tools.
And still, whenever I type in g++ --version, I get:
# g++ --version
couldn't understand kern.osversion `14.1.0'
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 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.
meaning, I am still using the old version of g++ and gcc.
Why wasn't it upgraded? I am interested in using c++0x in Eclipse, and for that I need a newer g++/gcc compiler.
EDIT: following the comment below, I have two questions:
Why
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
do I still seem to have an old version of clang?
Why didn't the installation of xcode and the command-line tools create the proper links to clang?
It looks like you maybe have an old version of xcode also installed.
From the command line you can switch to the proper one with
xcode-select --switch <path>
You should see something like this
$ g++ --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.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I had a similar problem installing ios-deploy after upgrading to yosemite. i was getting the same
couldn't understand kern.osversion `14.1.0'
for gcc. I ultimately solved it by:
cd /opt/local/bin/
sudo rm gcc
sudo ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/gcc gcc
This correctly pointed gcc to the the version provided by Xcode 6.1.
Related
I'm trying to build an OS Image for Raspberry pi on MacOS.
make failed because gcc is missing so I installed it with homebrew.
Still I cannot build the image due to the same error:
% make raspberrypi0w_defconfig
...
% make menuconfig
...
% brew install gcc
...
% brew list --versions gcc
gcc 11.3.0_2
% gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% make
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
You must install 'gcc' on your build machine
make: *** [dependencies] Error 1
Tried a make clean but I'm still getting the same error...
I ended up switching to gcc (it was a path issue).
clang is apple's C compiler, and when you type gcc, this is the compiler that is used by default. When you install gnu c, (using homebrew in my case), you still need to put it ahead of clang in the path.
However, using BuildRoot on MacOS ended up being a rabbit hole.
There are instructions here: https://github.com/generia/buildroot-osx
, but for me it was far simpler to setup an ubuntu VM and build on it. Which I did.
I have to run a code. The code includes mex files. For building that code, it required gcc version of 4.4.
Following is the description of system
Windows 10
Visual Studio 2012
Matlab 2017a
And gcc version of my system is:
$gcc --version
gcc --version
gcc (GCC) 7.4.0
I do not know how to downgrade it. I have tried so many steps, but no use.
You'll need to install it first - Please use a previous question on the subject here:
Next - choose to use it on Matlab via :
mex -setup
#mano Here's my output of the mex -setup
From the latest CS:GO update, a valve dev commented this on the reddit post:
We are upgrading the compiler toolchain we use to build CS:GO. This
pre-release branch has CS:GO built with the new toolchain. We are
releasing it as a pre-release branch to allow for testing ahead of it
being used in the next update.
There are no functional changes expected, though the new compiler
toolchain may yield a small performance boost.
Can anyone explain what a compiler toolchain is?
A tool chain is a set of tools (chain of tools) that are used to create a programmed product (runnable/executable program etc.).
Usually toolchains are used in the embedded world for cross-compiling, which means creating a program on a host which will eventually run on a different kind of target - therefore there is a need to create it with a specific compiler, linker, debugger etc.
In order to create from scratch a compiler for the target, you need to cross-compile it with a specific toolchain - that is the compiler toolchain.
So, by using the compiler toolchain you will be able to create a compiler for your target system.
A compiler toolchain is a set of tools, supporting libraries and header files that help build a program from source to an executable that can run on a machine. To see what different tools are invoked during a compilation process pass '-v' flag. e.g., gcc -v hello.c will print the following (Note comments # are mine):
$ /usr/local/Cellar/gcc/11.2.0/bin/gcc-11 -v hello.c
# Configuration options which were used to build gcc itself.
Using built-in specs.
COLLECT_GCC=/usr/local/Cellar/gcc/11.2.0/bin/gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.2.0 --libdir=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11 --disable-nls --enable-checking=release --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' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib --without-build-config --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0)
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-asm_macosx_version_min=11.5' '-mtune=core2' '-dumpdir' 'a-'
# Compiler invocation of cc1
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/cc1 -quiet -v -D__DYNAMIC__ hello.c -fPIC -quiet -dumpdir a- -dumpbase hello.c -dumpbase-ext .c -mmacosx-version-min=11.5.0 -mtune=core2 -version -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../../../../x86_64-apple-darwin20/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d0f2649375ab2f2193374e77e0a72e7c
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a-'
# Assembler invocation
as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=11.5 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx11.5.0 -filetype obj -main-file-name ccfvEkdl.s -target-cpu penryn -fdebug-compilation-dir /Users/Coolest -dwarf-debug-producer "Apple clang version 12.0.5 (clang-1205.0.22.9)" -dwarf-version=4 -mrelocation-model pic -mllvm -disable-aligned-alloc-awareness=1 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
COMPILER_PATH=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/
LIBRARY_PATH=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a.'
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 11.2.0
# linker invocation
/usr/bin/ld -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
#(#)PROGRAM:ld PROJECT:ld64-650.9
BUILD 00:19:30 Mar 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/
Note that a compiler toolchain is necessary to build executables but it is not sufficient. What is missing from the toolchain to have ‘everything’ that is needed to build executable programs is the ‘sysroot’.
Normally when we compile a program for the same machine the compiler uses the standard headers available in ‘/usr/include‘ and libraries from ‘/usr/lib‘. These paths are hardcoded in the compiler itself so we never have to think about it. However, when building a custom compiler or when cross-compiling programs we have to tell the compiler where the sysroot is by passing a flag e.g.
gcc --sysroot="/path/to/arm64/sysroot/usr" hello.c
Most often pre-packaged cross compilers come with a script/binary that has a ‘sysroot’ path embedded into it. e.g., aarch64-linux-gnu-gcc (https://packages.ubuntu.com/xenial/devel/gcc-aarch64-linux-gnu).
I have installed gcc 5.3.0(g++) and compiled mpich(mpic++) using that.
I already have my own Makefile, when i make from command line everything perfectly.
I also imported the project to eclipse PTP (Mars) and set the build option to make and set build folder to my source folder. Added my mpic++ and g++ paths to eclipse path environment variable.
When i build from eclipse, it finds and executes my make command, it even finds out my mpic++ but internally its using clang but not gcc
When i check mpic++ version on command line, i get
MacBook-Pro:mpi$ mpic++ --version
g++ (GCC) 5.3.0
Copyright (C) 2015 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.
And i added the same command to my make file so that i can check whats happening on eclipse, I get this
( mpic++ --version; )
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
So i am not sure what i missed here. How do i change my eclipse to use gcc instead of clang?
Thanks in advance.
I am using 32-bit eclipse CDT Kelper to manage a piece of code, which I could compile on command line but not with eclipse if I use any up-to-date c++11 feature. CDT tells me that "-std=c++11" is unrecognized.
After turning on the verbose option in project properties\settings\tool settings, I found that eclipse CDT somehow chooses an older version of MinGW that comes with Haskell platform 2013.2:
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-o' 'src\vaomp_bnb.o' '-shared-libgcc' '-mtune=i386' '-march=i386'
c:/haskell platform/2013.2.0.0/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe -quiet -v -iprefix c:\haskell platform\2013.2.0.0\mingw\bin\../lib/gcc/mingw32/4.5.2/ -dD ..\src\vaomp_bnb.cpp -quiet -dumpbase vaomp_bnb.cpp -mtune=i386 -march=i386 -auxbase-strip src\vaomp_bnb.o -g3 -O0 -Wall -version -fmessage-length=0 -o C:\DOCUME~1\ting\LOCALS~1\Temp\ccWNoh7I.s
GNU C++ (GCC) version 4.5.2 (mingw32)
I searched SO, and there is a similar question a half year ago here. But the answer there was about setting environment variables and didn't solve the problem.
In my case, CDT can find a MinGW GCC, but found the wrong one. I have installed tdm-gcc 64 bit with gcc-4.8.1, and Haskell platform. The tdm-gcc has priority and
gcc --version
on both DOS and MSYS shows
gcc.exe (tdm64-2) 4.8.1
I don't know what heuristic does CDT use to find toolchains. My question is, how can I tell CDT to use the gcc in a specific location, e.g. c:/MinGW?
Note, I can't uninstall the Haskell platform version of gcc as I will need HP.
Thanks,
I figured it out. It seems that Eclipse CDT does not take tdm-gcc MinGW 64-bit because eclipse itself is 32-bit. So it picked up the only 32-bit MinGW it can find, which is the old version from HP.
To verify this, I installed java 1.7 64-bit, and downloaded 64-bit version of Eclipse CDT (Kelper). Now, CDT automatically selects the TDM-GCC 64 version of MinGW gcc.
For those in a similar situation, one additional issue is that the 64-bit CDT - MinGW64 combination combination does not build projects. No binary/executable files are generated even for a newly created HelloWorld c++ project (even though compilation is OK). In my case, I changed the build tool in the project properties..\tool chain. from CDT internal builder to either of the other two options (one is Gnu's and another is a long name), and then the project can be successfully made to generate exe files.