/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
/usr/bin/make -f nbproject/Makefile-Debug.mk dist/Debug/GNU-MacOSX/cppapplication_1
mkdir -p build/Debug/GNU-MacOSX
rm -f build/Debug/GNU-MacOSX/main.o.d
g++ -arch i386 -c -g -MMD -MP -MF build/Debug/GNU-MacOSX/main.o.d -o build/Debug/GNU-MacOSX/main.o main.cpp
cc1plus: error: unrecognized command line option "-arch"
make[2]: *** [build/Debug/GNU-MacOSX/main.o] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 311ms)
simpatico$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.1/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5.1/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.5 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.5.1 (GCC)
This simple of a file:
#include <stdlib.h>
int main(int argc, char** argv) {
return (EXIT_SUCCESS);
}
The -arch option is part of the Apple extensions to gcc. You need to use the gcc supplied by Apple's Developer Tools, Xcode.
This error exists in many forms, regardless of the machine or build type.
The solution, in general, is to change the PATH and CROSS_COMPILE variables to include the correct cross compiler.
The -arch option is only in the Apple-provided version of gcc. Change CFLAGS (which might be set via your environment, your makefile, or your configure options) so it uses -march or -m32 instead. For example:
configure CFLAGS='-m32 -O2' CC=gcc-4.5
The difference seems to be that you can specify multiple -arch options to generate universal binaries, whereas -march only generates one at a time.
The macports version of GCC doesn't support the -arch flag. As it turns out Apple's GCC is a wrapper around the real gcc that honors a few special flags before calling the real compiler. The -arch flag is one of these flags. It calls the appropriate compiler for each of the archs specified and then uses lipo to mash all of the object files back together into a "fat" object file.
I just spent a little bit of time getting this Apple GCC wrapper working with macports GCC. If you want the details you can find them here:
http://thecoderslife.blogspot.com/2015/07/building-with-gcc-46-and-xcode-4.html
Related
Im compiling a program I made using make and I get this error
c++: error: unrecognized command-line option ‘-target’
make[3]: *** [libs/system/CMakeFiles/system.dir/build.make:76: libs/system/CMakeFiles/system.dir/src/system/syscalls.cpp.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:504: libs/system/CMakeFiles/system.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:243: CMakeFiles/image-uefi.dir/rule] Error 2
make: *** [Makefile:137: image-uefi] Error 2
Im running Arch Linux with Clang-13, CMake and all of base-devel installed.
Any help would be appreciated, please dont be condescending I just installed Arch Linux and am getting this error, in Fedora compiling the exact same app provides no error.
The line which created the error is this, it should be the offending linux since the error in question(the top line) complains about -target being unrecognized.
cd /home/user/toy-kernel/build/libs/system && /usr/bin/c++ -I/home/user/toy-kernel/libs/system/src -target x86_64-none-elf -mcmodel=kernel -fno-exceptions -fno-use-cxa-atexit -fno-rtti -nostdlib -ffreestanding -fno-threadsafe-statics -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-sse4.1 -mno-sse4.2 -mno-sse4a -mno-3dnow -mno-3dnowa -std=gnu++20 -MD -MT libs/system/CMakeFiles/system.dir/src/system/syscalls.cpp.o -MF CMakeFiles/system.dir/src/system/syscalls.cpp.o.d -o CMakeFiles/system.dir/src/system/syscalls.cpp.o -c /home/user/toy-kernel/libs/system/src/system/syscalls.cpp
In my case, c++ was the g++ compiler instead of the clang compiler, if you are having a similar issue try updating g++ or clang++(on older macs you may need to have to use brew to install those) or going in your /usr/bin directory(for mac and linux, I never used windows cant help you) and replacing the files(though only do that if you absolutely know what your doing!).
Aim Compile a C++ program on Windows for ARM using only LLVM.
Why LLVM because of permissive licensing.
I'm starting to wonder if my understanding of LLVM is correct.
On the host machine do
Use clang (front end) to generate intermediate representation. This representation is target independent.
Use llc (back end) to generate target assembly code.
Use lld-link.exe to produce executable.
Then execute on the target machine.
Host machine Windows 10, 64bit
Target machine Drive PX with a arm cortex-a57
The program
int main(int argc, char* argv[])
{
int x=41;
x++;
return x;
}
I've checked out and compiled LLVM (using Visual Studio 2015, Release build, CPU= x64)
My attempts
clang.exe -target arm -march=armv8-a -mcpu=cortex-a57 -mfloat-abi=hard -emit-llvm -c -o main.bc main.cpp
llc.exe -march=arm -mcpu=cortex-a57 -mattr=a57,armv8-a,v8 -meabi=gnu -o main.s main.bc
lld-link.exe /entry:main /machine:arm main.s
Error
lld-link.exe: error: main.s: unknown file type
Then I tried doing the front-end steps on Windows and the back-end on the arm machine.
clang.exe -target arm -march=armv8-a -mcpu=cortex-a57 -mfloat-abi=hard -emit-llvm -c -o main.bc main.cpp
llc.exe -march=arm -mcpu=cortex-a57 -mattr=a57,armv8-a,v8 -meabi=gnu -o main.s main.bc
SCP main.s to the arm machine. SSH and
gcc main.s (using gcc as a test. LLVM should do this.)
Error
main.s: Assembler messages:
main.s:2: Error: unknown pseudo-op: `.syntax'
main.s:3: Error: unknown pseudo-op: `.eabi_attribute'
main.s:9: Error: unknown pseudo-op: `.fpu'
main.s:26: Error: junk at end of line, first unrecognized character is `#'
main.s:29: Error: unknown pseudo-op: `.code'
main.s:31: Error: unknown pseudo-op: `.fnstart'
main.s:32: Error: junk at end of line, first unrecognized character is `#'
main.s:34: Error: operand 1 should be an integer register -- `mov r2,#0'
main.s:41: Error: operand 1 should be an integer or stack pointer register -- `add r0,r0,#1'
main.s:45: Error: unknown mnemonic `bx' -- `bx lr'
main.s:48: Error: unknown pseudo-op: `.cantunwind'
main.s:49: Error: unknown pseudo-op: `.fnend'
main.s:50: Error: junk at end of line, first unrecognized character is `#'
So I tried to target only Windows
clang.exe -emit-llvm -c -o main.bc main.cpp
llc.exe -march=x86 -c -o main.s main.bc
ld.lld.exe main.s
Error
ld.lld.exe: error: main.s:1: unknown directive: .text
Then, instead of ld.lld.exe use gcc (Again using gcc as a test. LLVM should do this.)
clang.exe -emit-llvm -c -o main.bc main.cpp
llc.exe -march=x86 -c -o main.s main.bc
gcc main.s -o main.exe
That works. To test I type
main.exe
echo Exit Code is %errorlevel%
Which returns 42
General question
What are the steps to compile a C++ program under Windows targeting an arm CPU using only LLVM (no gcc, nothing downloaded from ARM)?
Specific questions
Can the tools that come with self-compiled LLVM (e.g. clang.exe, llc.exe, lld.exe) compile an executable on Windows targeting arm? E.g is lld still under development?
Why does my attempt to compile and link under Windows, targeting Windows fail?
Where do the header files and libraries (e.g. libstdc++) come from when linking on the host for the target? I suppose I need to get those from the arm machine? Copy them to the host and tell the linker where to find them ? Is that correct?
Update
So I originally tried Cross-compilation using Clang
clang.exe --target=arm --sysroot=c:\code\clang\FromCmdLine main.cpp -v
The result is
clang.exe: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
And the details of -v are
"C:\\llvm\\clang.exe" -cc1 -triple armv4t-- -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu arm7tdmi -target-feature +soft-float -target-feature +soft-float-abi -target-feature -fp-only-sp -target-feature -d16 -target-feature -vfp2 -target-feature -vfp3 -target-feature -fp16 -target-feature -vfp4 -target-feature -fp-armv8 -target-feature -neon -target-feature -crypto -target-feature +strict-align -target-abi aapcs -msoft-float -mfloat-abi soft -fallow-half-arguments-and-returns -dwarf-column-info -debugger-tuning=gdb -v -resource-dir "c:\\llvm\\clang\\7.0.0" -isysroot "c:\\code" -fdeprecated-macro -fdebug-compilation-dir "c:\\code" -ferror-limit 19 -fmessage-length 293 -fno-signed-char -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o "C:\\Users\\AppData\\Local\\Temp\\main-b17d06.o" -x c++ main.cpp
clang -cc1 version 7.0.0 based upon LLVM 7.0.0svn default target x86_64-pc-win32
ignoring nonexistent directory "c:\code\usr/local/include"
ignoring nonexistent directory "c:\code\usr/include"
#include "..." search starts here:
#include <...> search starts here:
C:\llvm\clang\7.0.0\include
End of search list.
"C:\\MinGW\\bin\\gcc.exe" "--sysroot=c:\\code" -v -o a.out "C:\\Users\\AppData\\Local\\Temp\\main-b17d06.o"
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/6.3.0/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../;c:/code/clang/FromCmdLine/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'a.out' '-mtune=generic' '-march=i586'
c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/collect2.exe -plugin c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/liblto_plugin-0.dll -plugin-opt=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe -plugin-opt=-fresolution=C:\Users\AppData\Local\Temp\ccufvVIA.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt --sysroot=c:\code\clang\FromCmdLine -Bdynamic -o a.out c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../crt2.o c:/mingw/bin/../lib/gcc/mingw32/6.3.0/crtbegin.o -Lc:/mingw/bin/../lib/gcc/mingw32/6.3.0 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../.. -Lc:/code/clang/FromCmdLine/lib C:\Users\AppData\Local\Temp\main-b17d06.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/6.3.0/crtend.o
c:/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: C:\Users\AppData\Local\Temp\main-b17d06.o: Relocations in generic ELF (EM: 40)
C:\Users\AppData\Local\Temp\main-b17d06.o: error adding symbols: File in wrong format
Update
This does not fully answer my question but it does help me to progress.
For a better understanding I found crosstool-NG useful, especially their documentation (chapters 1 to 5).
Then I read the cmake cross compiling documentation.
The I wrote a small cmake C++ test.
Helloworld.cpp
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "Hello World!" << std::endl;
return 0;
}
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.9)
project (hello)
add_executable(hello helloworld.cpp)
Target specific configuration for cmake. This is from 4.
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_SYSROOT /home/user/x-tools/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/)
set(CMAKE_STAGING_PREFIX /home/user/crosscompile/stage)
set(tools /home/user/x-tools/aarch64-unknown-linux-gnueabi)
set(CMAKE_C_COMPILER ${tools}/bin/aarch64-unknown-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/aarch64-unknown-linux-gnueabi-g++)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
And the command line
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain_file.txt ..
That cross compiles to ARM and the program runs on the ARM machine.
But this does not use LLVM / Clang. To use LLVM I thought of changing the toolchain configuration to use
set(tools /usr/bin)
set(CMAKE_C_COMPILER ${tools}/clang)
set(CMAKE_CXX_COMPILER ${tools}/clang++)
That failed because that bin folder is for the host machine.
I also tried using the AArch64 download from http://releases.llvm.org/download.html. Yes that also did not work.
So in summary this what is required.
A sysroot folder with the lib and include folders for the target system. Okay there needs to be more in that sysroot folder than lib and include.
A toolchain (compiler, assembler, linker) for the target system.
This is what I had to do, to get a proof-of-concept working, to cross compile using only llvm, with host=linux x86_64 and target = DrivePX (arm aarch64). (Also worked with host=Windows 10 x86_64.)
I recommend a tool like croostool-ng which sets up a cross compilation toolchain for you, but the steps below show what's going on behind the scenes, and it uses only llvm.
On the host computer, checkout and compile LLVM including Clang
see http://llvm.org/docs/GettingStarted.html.
This takes a long time so do a release build. Also make sure you have plenty of space (GB).
To tell cmake to do a release build e.g.
CC=gcc CXX=g++ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ../llvm/
Then call make.
Call clang on the host computer.
Remember to set the target, e.g. --target=aarch64-linux-gnu
Tell clang to use the llvm linker, i.e. -fuse-ld=lld
clang --target=aarch64-linux-gnu -v main.cpp -o main -fuse-ld=lld
There will be a lot of linker errors
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
And some more errors about missing crtX.o files, e.g.
ld.lld: error: cannot open crt1.o: No such file or directory
On the target machine find, all the libgcc, libc, etc. files.
Remember to copy the fully versioned libraries, e.g. for libgcc_s.so copy libgcc_s.so.1
Copy these files to the host computer.
Tell clang where to find these libraries, e.g. Copy the files into a folder called libs
clang --target=aarch64-linux-gnu -v main.cpp -o main -fuse-ld=lld -L./libs
Also remember that the linker is looking for e.g. libgcc_s.so so create symbolic links to e.g. libgcc_s.so.1.
Copy the crtX.o files from the target to the host. Put them next to the main.cpp.
Then one more error
ld.lld: error: undefined symbol: __libc_csu_fini
That symbol is located in libc_nonshared.a. And this answer helped.
libc.so is a linker script which tells the linker to pull in the shared library libc.so.6, and a non-shared portion, libc_nonshared.a
On the host find and open libc.so and see where libc.so.6 and libc_nonshared.a are located.
Copy them to host.
Tell the linker to use those 2 libraries, i.e. -lc -lc_nonshared
clang --target=aarch64-linux-gnu -v main.cpp -o main -fuse-ld=lld -L./libs -lc -lc_nonshared
My short text code only depends on libc, libgcc and requires no header files. If your code requires other libraries and header files you would have to copy them from the target to the host.
Update
Read this question if you are wondering about libgcc.
I set up NetBeans 8.1 on Linux Mint to compile C/C++. Everything went fine at first, until I tried using C++14.
I changed the settings for C++ from C++98 to C++11. There was an error in the program which I fixed. I got distracted and changed the settings again to use C++14. g++, or at least the version I have installed, does not support C++14, so I changed it back to C++11, but it's still using C++14 of its own accord. I tried changing it to C++11 and back again, and then to C++11 again. C++11 works for sure, because I've used that tag with success in the past.
Here is the build log:
cd '/home/.../NetBeansProjects/Sun Storm'
/usr/bin/make -f Makefile CONF=Debug
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: Entering directory `/home/.../NetBeansProjects/Sun Storm'
"/usr/bin/make" -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux/sun_storm
make[2]: Entering directory `/home/.../NetBeansProjects/Sun Storm'
mkdir -p build/Debug/GNU-Linux
rm -f "build/Debug/GNU-Linux/main.o.d"
g++ -c -g -std=c++14 -MMD -MP -MF "build/Debug/GNU-Linux/main.o.d" -o build/Debug/GNU-Linux/main.o main.cpp
g++: error: unrecognized command line option ‘-std=c++14’
make[2]: *** [build/Debug/GNU-Linux/main.o] Error 1
make[2]: Leaving directory `/home/.../NetBeansProjects/Sun Storm'
make[1]: *** [.build-conf] Error 2
make[1]: Leaving directory `/home/.../NetBeansProjects/Sun Storm'
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 76ms)
By seeing g++ -c -g -std=c++14, it is safe to assume that NetBeans is still using C++14, even though it is set to use C++11. How can I get NetBeans to use the settings that are actually there instead of making them up on its own?
Note: I couldn't find anything on the Internet about NetBeans not following the given settings.
I also tried deactivating the C/C++ plugin, restarting the IDE, and then activating it again. I also tried installing the GNU Standard C++ Library v3. Nothing changed.
Have you tried to change your "g++" call to devtoolset-2 ?
File->Project Properties -> Build -> Tools Colection->
Click in Version and you will see with compilers Netbeans is using
++++++++++++++++++++++++++++++++++++++++++++++++++++
C Compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
C++ Compiler: g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Fortran Compiler: Tool not found
Assembler: GNU assembler version 2.20.51.0.2-5.44.el6 20100205
Make Tool: GNU Make 3.81
Debugger: Tool not found
QMake Tool: Tool not found
CMake Tool: Tool not found
++++++++++++++++++++++++++++++++++++++++++++++++++++
I am trying to make using g++. At first, I upgraded my gcc version by compiling the package locally, and add some environment path to my ~/.bashrc
alias gcc='/home/rescape/lib/bin/gcc'
alias g++='/home/rescape/lib/bin/g++'
export CC=/home/rescape/lib/bin/gcc
export CPP=/home/rescape/lib/bin/cpp
export CXX=/home/rescape/lib/bin/c++
And I try g++ -v in terminal:
[rescape#iZ231twjza6Z mxnet]$ g++ -v
Using built-in specs.
COLLECT_GCC=/home/rescape/lib/bin/g++
COLLECT_LTO_WRAPPER=/home/rescape/lib/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-checking=release --enable-languages=c,c++ --disable-multilib --prefix=/home/rescape/lib/
Thread model: posix
gcc version 4.8.0 (GCC)
Still, When I do make, such error message occurs:
[rescape#iZ231twjza6Z mxnet]$ make
g++ -std=c++0x -DMSHADOW_FORCE_STREAM -Wall -O3 -I./mshadow/ -I./dmlc-core/include -fPIC -Iinclude -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CUDA=0 -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -DMXNET_USE_OPENCV=1 `pkg-config --cflags opencv` -fopenmp -MM -MT build/resource.o src/resource.cc >build/resource.d
cc1plus: error: unrecognized command line option "-std=c++0x"
make: *** [build/resource.o] Error 1
Any suggestions of how to fix this? Thanks!
According to this:
[rescape#iZ231twjza6Z mxnet]$ make
g++ ...
You not use CXX variable in your Makefile, so just replace g++ with CXX in your Makefile. aliases works only when you enter commands in your shell, if you type g++ something.cpp bash execute /home/bin/g++ something.cpp, that's all, bash aliasing not help if external process (in our case make) execute g++
I'm having problem installing on OS X 10.10 Yosemite, running with gcc4.9.2 and qt 4.8.6 installed via Brew.
gem install capybara-webkit
Building native extensions. This could take a while...
ERROR: Error installing capybara-webkit:
ERROR: Failed to build gem native extension.
/usr/local/var/rbenv/versions/2.1.4/bin/ruby extconf.rb
cd src/ && /usr/local/bin/qmake /usr/local/rbenv/gem/gems/capybara-webkit-1.3.1/src/webkit_server.pro -spec /usr/local/Cellar/qt/4.8.6/mkspecs/macx-g++ -o Makefile.webkit_server
cd src/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile.webkit_server
g++ -pipe -O2 -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.5 -Wall -W -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Cellar/qt/4.8.6/mkspecs/macx-g++ -I. -I/usr/local/Cellar/qt/4.8.6/lib/QtCore.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtCore.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtNetwork.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtNetwork.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtGui.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtGui.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtWebKit.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtWebKit.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/include -Ibuild -F/usr/local/Cellar/qt/4.8.6/lib -x c++-header -c stable.h -o build/webkit_server.gch/c++
g++: error: unrecognized command line option '-Xarch_x86_64'
make[1]: *** [build/webkit_server.gch/c++] Error 1
make: *** [sub-src-webkit_server-pro-make_default-ordered] Error 2
Command 'make' failed
I had the same problem using GCC installed via MacPorts (tested several versions up to gcc5). The solution for me was using g++ supplied with the XCode command line tools. I uninstalled all MacPorts GCC versions. Below version details of the g++ command that worked.
$ g++ --version
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.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
A similar problem was asked here: QT Creator adds -Xarch.