I trying to get a cmake build system working on linux. The project contains a bunch of executables and two libraries. One of the executables is first built as a library, then that library is linked with the object file containing the man subroutine. This was done because the rest of the executables depend on that library. The tricky part is that the main subroutine is defined inside a module that the rest of sources depend on so this needs to be compiled before the rest of the sources. The effect is that the main subroutine gets added to the resulting library. This seems to work fine on Mac OS X but, the linking state fails on Linux.
The cmake file for the failing part looks like
cmake_minimum_required (VERSION 2.8)
# Create an empty variable to hold all the source files.
set (vmec_sources "")
# Add subdirectory for all the sources.
add_subdirectory (Sources)
add_library (vmec STATIC ${vmec_sources})
add_dependencies (vmec stell)
# Define an executable and link all libraries.
add_executable (xvmec ${CMAKE_CURRENT_SOURCE_DIR}/Sources/General/vmec_main.f)
add_dependencies (xvmec vmec)
target_link_libraries (xvmec vmec stell)
if ((NOT ${NETCDF_C} STREQUAL "") AND (NOT ${NETCDF_F} STREQUAL ""))
target_link_libraries (xvmec ${NETCDF_C} ${NETCDF_F})
endif ()
When running cmake, everything configures fine and generates a make file when I run make Mac OS X everything works fine. When I run make on Linux it fails.
The output from the make VERBOSE=1 On Linux produces
Linking Fortran executable ../build/bin/xvmec
cd /home/user/reconstruction/VMEC2000 && /usr/bin/cmake -E cmake_link_script CMakeFiles/xvmec.dir/link.txt --verbose=1
/usr/bin/gfortran -cpp -D NETCDF -I /usr/include CMakeFiles/xvmec.dir/Sources/General/vmec_main.f.o -o ../build/bin/xvmec -rdynamic ../build/lib/libvmec.a ../build/lib/libstell.a /usr/lib/libnetcdf.so /usr/lib/libnetcdff.so
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/libgfortranbegin.a(fmain.o): In function `main':
(.text+0x26): undefined reference to `MAIN__'
collect2: ld returned 1 exit status
make[2]: *** [build/bin/xvmec] Error 1
make[2]: Leaving directory `/home/user/reconstruction'
make[1]: *** [VMEC2000/CMakeFiles/xvmec.dir/all] Error 2
make[1]: Leaving directory `/home/user/reconstruction'
make: *** [all] Error 2
On Mac OS X, I get
Linking Fortran executable ../build/bin/xvmec
cd /Users/user/repo/trunk/VMEC2000 && "/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/xvmec.dir/link.txt --verbose=1
/usr/local/bin/gfortran -framework Accelerate -cpp -D DARWIN -D NETCDF -I /Users/user/NetCDF/include -O3 -ftree-vectorize -m64 -march=native -fomit-frame-pointer -falign-functions -mfpmath=sse CMakeFiles/xvmec.dir/Sources/General/vmec_main.f.o -o ../build/bin/xvmec ../build/lib/libvmec.a ../build/lib/libstell.a /Users/user/NetCDF/lib/libnetcdf.dylib /Users/user/NetCDF/lib/libnetcdff.dylib
"/Applications/CMake 2.8-8.app/Contents/bin/cmake" -E cmake_progress_report /Users/user/repo/trunk/CMakeFiles 100
[100%] Built target xvmec
The link line looks like it is linking all the same stuff in the correct order so I don't understand why this is failing on Linux.
Turns out I had the wrong file listed as containing the main method. It seems that later versions of gfortran can link 'MAIN__' from a inside a library while gfortran-4.4 cannot.
Related
I have no trouble building my application under Visual Studio's environment, but due to lack of experience, I am having trouble under Linux/GCC. Although GCC compiles my app successfully, but it reports linker errors.
The first thing I did was to build a shared library using CMakeLists.txt. The file has no ‘make install’ so I manually copied the shared library file to a global location as follows:
sudo cp libibpp.a /usr/local/lib/
Since applications built with the IBPP library require you to include a single header file, I copied it to a global location:
sudo cp ibpp.h /usr/local/include/
So far, so good but when I run CMake for my application, I am getting linker errors such as:
undefined reference to ‘isc_create_database’
I am successfully using many ‘shared libraries’ in my application (such as Boost Regex/Filesystem/Chrono/DateTime/Thread). The only ‘static library’ that I am using is IBPP (libibpp.a).
I suspect that I am missing something in my application’s CMakeListst.txt:
cmake_minimum_required(VERSION 3.10.2)
project(myapp)
file(GLOB src "*.h" "*.cpp")
add_executable(myapp ${src})
target_link_libraries(myapp ibpp icuuc icudata boost_regex boost_system boost_filesystem
boost_chrono boost_date_time boost_thread pthread)
add_definitions(-DIBPP_LINUX)
Can someone provide me with some hints as to why I get linker errors related to IBPP?
UPDATED:
User n.m. asked me to build using the VERBOSE option, so here is the output:
/usr/bin/cmake -E cmake_link_script CMakeFiles/myapp.dir/link.txt --verbose=1
/usr/bin/c++ CMakeFiles/myapp.dir/appServer.cpp.o CMakeFiles/myapp.dir/app_env.cpp.o CMakeFiles/myapp.dir/app_setting.cpp.o CMakeFiles/myapp.dir/authenticationServer.cpp.o CMakeFiles/myapp.dir/bustacheTestStencil.cpp.o CMakeFiles/myapp.dir/commonKeys.cpp.o CMakeFiles/myapp.dir/dataFetcher.cpp.o CMakeFiles/myapp.dir/fighterKeys.cpp.o CMakeFiles/myapp.dir/fighterProfileJsonGenerator.cpp.o CMakeFiles/myapp.dir/fighterProfileMarkupGenerator.cpp.o CMakeFiles/myapp.dir/fighterStorage.cpp.o CMakeFiles/myapp.dir/forwardProxyServer.cpp.o CMakeFiles/myapp.dir/headerProcessor.cpp.o CMakeFiles/myapp.dir/homepageStencil.cpp.o CMakeFiles/myapp.dir/httpUtils.cpp.o CMakeFiles/myapp.dir/locale.cpp.o CMakeFiles/myapp.dir/main.cpp.o CMakeFiles/myapp.dir/markupServer.cpp.o CMakeFiles/myapp.dir/myTools.cpp.o CMakeFiles/myapp.dir/stdafx.cpp.o CMakeFiles/myapp.dir/unicodeFunctions.cpp.o CMakeFiles/myapp.dir/utils.cpp.o -o myapp -libpp -licutu -licutest -licuio -licui18n -licuuc -licudata -lboost_regex -lboost_system -lboost_filesystem -lboost_chrono -lboost_date_time -lbustache -lboost_thread -lpthread
//usr/local/lib/libibpp.a(_ibpp.cpp.o): In function `ibpp_internals::GDS::Call()':
_ibpp.cpp:(.text+0x2c): undefined reference to `isc_create_database'
_ibpp.cpp:(.text+0x3b): undefined reference to `isc_attach_database'
....
_ibpp.cpp:(.text+0x2bd): undefined reference to `isc_service_start'
_ibpp.cpp:(.text+0x2cf): undefined reference to `isc_service_query'
collect2: error: ld returned 1 exit status
CMakeFiles/myapp.dir/build.make:640: recipe for target 'myapp' failed
make[2]: *** [myapp] Error 1
make[2]: Leaving directory '/home/carol/Documents/vm_shared/AppServer/build'
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/myapp.dir/all' failed
make[1]: *** [CMakeFiles/myapp.dir/all] Error 2
make[1]: Leaving directory '/home/carol/Documents/vm_shared/AppServer/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Problem solved thanks to comment by n.m. above. Since I was not including libfbclient, I was getting the "undefined references to 'isc_create_database', and other 'isc_...' messages.
Using the settings below, I am now able to use my precompiled/built IBPP library instead of having to include the source code into my application!
Here is a simplified, very barebones CMakeLists.txt that demonstrates what is required to get your IBPP.a implemented into your app without having to include the IBPP source into your app:
file(GLOB src "*.cpp")
add_executable(myapp ${src})
target_link_libraries(myapp ibpp fbclient)
Make note of the order, libibpp must be before libfbclient.
I'm trying to cross compile perl 5.24 using following method since the target machine does not have ssh installed.
https://github.com/arsv/perl-cross
Just for Fyi, my local machine is ubuntu x86_64 GNU/Linux.
I configure the toolchain with the following option:
./configure -Dsysroot=$QNX_TARGET -Dcc=ntoarmv7-gcc -Dtargetarch=armle -Dprefix=$HOME/localperl -Duseshrplib
The reason I think the above scripts worked just fine because it generates the makefile with the following message:
Generating config.h
Extracting config.h (with variable substitutions)
Generating Makefile.config
Configuration completed for native build
platform: x86_64-
c compiler: ntoarmv7-gcc
ld: ntoarmv7-gcc
ar: ar
ranlib: ranlib
when i run the make -j4 option i end up getting either of the following 2 results:
./generate_uudmap uudmap.h bitcount.h mg_data.h
./generate_uudmap: 1: ./generate_uudmap: Syntax error: word unexpected (expecting ")")
make: *** [uudmap.h] Error 2
OR
cp -f op.c opmini.c
cp -f perl.c perlmini.c
cp -f ext/re/re.pm lib/re.pm
sh cflags.SH
cp -f dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp lib/ExtUtils/xsubpp
ntoarmv7-gcc -DPERL_CORE --sysroot=/opt/qnx650/target/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -Wno-unused-function -c -o op.o op.c
./miniperl_top lib/unicore/mktables -w -C lib/unicore -P pod -maketest -makelist -p
./miniperl_top: no ./miniperl found; build it before using miniperl_top
make: *** [lib/unicore/CombiningClass.pl] Error 1
I couldn't find much info on how to resolve the above issues. Could it be because i have not provided correct setting options for ./configure ?? If so, can you provide more insight on this.
EDIT:
It looks like i was passing the wrong information to ./configure script (it was considering it as the native rather than cross), I updated it with the following and was able to make bit of progress.
./configure -Dsysroot=/opt/qnx6 -Dcc=arm-unknown-nto-qnx6.6.0eabi-gcc --target-tools-prefix=arm-unknown-nto-qnx6.6.0eabi- --target=arm-unknown-nto-qnx6.6.0eabi --host=arm-unknown-nto-qnx6.6.0eabi -Dprefix=$HOME/localperl
with this, the configuration was successfull for the cross platform. Now when I perform the make, it runs fine for a bit and I run it following error
arm-unknown-nto-qnx6.6.0eabi-ar cru libperl.a op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o dquote.o util.o mg.o reentr.o mro_core.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o keywords.o caretx.o time64.o DynaLoader.o
arm-unknown-nto-qnx6.6.0eabi-ranlib libperl.a
./miniperl_top statars > static.list
./miniperl_top extlibs > ext.libs
arm-unknown-nto-qnx6.6.0eabi-gcc -DPERL_CORE --sysroot=/opt/qnx6 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o perlmain.o perlmain.c
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx6 -Wl,-E -o perl perlmain.o libperl.a
libperl.a(pp.o): In function `Perl_pp_crypt':
pp.c:(.text+0xffd8): warning: The 'crypt' function has been deprecated in libc. Link against liblogin for extended algorithm support.
libperl.a(toke.o): In function `Perl_scan_num':
toke.c:(.text+0x27b82): undefined reference to `pow'
libperl.a(util.o): In function `Perl_drand48_r':
util.c:(.text+0xa36e): undefined reference to `ldexp'
libperl.a(sv.o): In function `S_hextract':
sv.c:(.text+0x13ca0): undefined reference to `frexp'
libperl.a(sv.o): In function `Perl_sv_vcatpvfn_flags':
sv.c:(.text+0x16cc0): undefined reference to `frexp'
libperl.a(time64.o): In function `Perl_gmtime64_r':
time64.c:(.text+0x338c): undefined reference to `fmod'
.
.
time64.c:(.text+0x359c): undefined reference to `floor'
time64.c:(.text+0x37e6): undefined reference to `ceil'
collect2: error: ld returned 1 exit status
make: *** [perl] Error 1
final problem was related to linking the libraries. adding -lm fixed the problem
arm-unknown-nto-qnx6.6.0eabi-gcc --sysroot=/opt/qnx660/target/qnx6 -Wl,-rpath,/home/swgroup/localperl/lib/perl5/5.24.0/arm-/CORE -Wl,-E -o perl perlmain.o libperl.so -lm
I'm trying to use MinGW-W64 instead of MinGW in Codelite. When I compile simple "hello, world" project it's all right. But when I try to link some libraries, I get a strange linker error. Project with exactly same settings compiles by MinGW with any problems. There are build output for both variants:
MinGW GCC 4.8.1
`C:\Windows\system32\cmd.exe /C D:/apps/mingw/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
====0 errors, 0 warnings====`
MinGW-W64 GCC 5.2.0
`C:\Windows\system32\cmd.exe /C D:/apps/mingw-w64/mingw32/bin/mingw32-make.exe -j8 SHELL=cmd.exe -e -f Makefile
"----------Building project:[ code - Debug ]----------"
mingw32-make.exe[1]: Entering directory 'D:/Projects/codelite/code'
codelite-cc D:/apps/mingw-w64/mingw32/bin/g++.exe -c "D:/Projects/codelite/code/src/main.cpp" -Wfatal-errors -g -O0 -pedantic -W -std=c++11 -Wall -o ./Debug/src_main.cpp.o -I./inc/
D:/apps/mingw-w64/mingw32/bin/g++.exe -o bin/code #"code.txt" -L./lib/ -lopengl32
g++.exe: error: #code.txt -L./lib/: No such file or directory
mingw32-make.exe[1]: *** [bin/code] Error 1
code.mk:78: recipe for target 'bin/code' failed
mingw32-make.exe[1]: Leaving directory 'D:/Projects/codelite/code'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
====1 errors, 0 warnings====`
This looks like a bug in your toolchain and not in CodeLite.
There is a space between the "#code.text" and -L./lib and for some reason g++ does not see it...
I put my money on the mingw32-make tool. You can tell CodeLite to use the mingw32-make.exe from the 4.8.1 version (which worked): settings->build settings->compilers->[YOUR COMPILER NAME]->Make
Another option is to disable the option that tells CodeLite to generate Makefile that passes the object list via file to the compiler:
Settings->Build Settings->compilers->[YOUR COMPILER NAME]->Advanced tab and uncheck the option: pass object list to the linker via file
Lately i too have found the similar problem. Later i was able to figure out the issue. We just to need to go to the project settings under change makefile generator default to codelite makefile generator i think that will work.
I'm trying to build my own library. It worked on x86 linux so I wanna build for MIPS Linux (Little endian.)
I'm using sourcery codebench in Mento Graphics and buildroot and CMake.
I configured build_all.sh like below.
#!/bin/bash -ev
export TARGETROOT="/usr/mipsel-buildroot-linux-gnu/sysroot"
mkdir -p mips_build
cd mips_build
cmake -DCMAKE_SYSTEM_NAME="Linux" \
-DCMAKE_C_COMPILER="${CROSS_COMPILE}gcc" \
-DCMAKE_CXX_COMPILER="${CROSS_COMPILE}g++" \
-DCMAKE_AR="${CROSS_COMPILE}ar" \
-DCMAKE_C_FLAGS="-EL -c -g -O2 -fPIC --sysroot=$TARGETROOT " \
-DCMAKE_CXX_FLAGS="-EL -c -g -O2 -fPIC --sysroot=$TARGETROOT " \
../
make
cd ..
Where $CROSS_COMPILE=/home/vagrant/bd1/mips-2014.05/bin/mips-linux-gnu-
And CMakeFiles.txt is like below.
make_minimum_required (VERSION 2.6)
set(EMSG_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../src/eagle_msg/include )
set(EMSG_LIB_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../../lib )
set (PROJECT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src)
set (PROJECT_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/include)
set (PROJECT_LIB_DIR ${CMAKE_CURRENT_SOURCE_DIR}/lib)
set(LIBRARIES
libemsg.a
libzmq.a
libprotobuf.a
libprotobuf-c.a
libpthread.a
libstdc++.a
)
#For controller : Client
SET(EXECUTABLE test_controller)
project (${EXECUTABLE})
include_directories(
${PROJECT_INCLUDE_DIR}
${EMSG_INCLUDE_DIR}
$ENV{TARGETROOT}/usr/include
)
link_directories(
${PROJECT_LIB_DIR}
${EMSG_LIB_DIR}
$ENV{TARGETROOT}/usr/lib
)
set(SRCS
test_controller.cpp
)
add_executable( ${EXECUTABLE} ${SRCS})
target_link_libraries( ${EXECUTABLE} ${LIBRARIES} )
Then it makes the error like below.
[ 40%] Built target emsg
Linking CXX executable ../../../bin/test_controller
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [../bin/test_controller] Error 1
make[1]: *** [test/emsg_test/CMakeFiles/test_controller.dir/all] Error 2
So I checked the format of libstdc++.so. Then it's ELF 32-bit LSB shared object, MIPS, MIPS32. That's the right version. Then what can I do to solve?
/usr/mipsel-buildroot-linux-gnu/sysroot# file /usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.*
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.a: current ar archive
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so: symbolic link to `libstdc++.so.6.0.19'
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so.6: symbolic link to `libstdc++.so.6.0.19'
/usr/mipsel-buildroot-linux-gnu/sysroot/usr/lib/libstdc++.so.6.0.19: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, not stripped
New information
It seems to be the problem of buildroot. I checked the sysroot value of mips-linux-gnu-gcc.
This is the result before installing buildroot.
$ mips-linux-gnu-gcc --print-sysroot
/home/vagrant/bd1/mips-2014.05/bin/../mips-linux-gnu/libc
This is the result after installing buildroot.
$ mips-linux-gnu-gcc --print-sysroot
/usr/usr/mipsel-buildroot-linux-gnu/sysroot/soft-float/el
I also found the post about similar problem. But it's old issue.
Please use the CMake toolchain file provided by Buildroot. It is generated in $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake. Use it this way:
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/host/usr/share/buildroot/toolchainfile.cmake
And then you can remove all your other -DCMAKE_ variable, since the toolchain file indicates to CMake which compiler to use, which flags, etc.
I found the reason. The main reason is sysroot path. Buildroot organizes all toolchain into $BUILDROOT/output/host/. So you should change the PATH environment like below.
HOST_BINARY="$BUILDROOT/output/host/usr/bin"
PATH="${PATH}:${HOST_BINARY}"
Where $BUILDROOT is the folder where buildroot is extracted.
You should use toolchain below $BUILDROOT/output/host/usr/bin.
I have some trouble with crosscompiling C++ program which takes advantage of openMP library. I am using Linux Ubuntu 12.04 LTS. I want to obtain executable file runnable on Windows.
I have no problem with compiling my program with OMP with regular g++ command:
g++ a.cpp b.cpp -o OMPres -pg -O3 -I./CBLAS/include -L./ -lcblas
Also when I try crosscompilation without OMP, everything runs perfectly fine:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o res.exe -l gfortran -static
But when I try to crosscompile it with OMP using following command:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I get this error:
a.cpp:41:17: fatal error: omp.h: No such file or directory
compilation terminated.
I found where omp.h file is located on my disk, and added the path to the command. After executing it:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I got another error: x86_64-w64-mingw32-g++: error: libgomp.spec: No such file or directory
As I also have this file on the disk I tried to copy it in various places and finaly it worked when I copied it directly into the directory where compilation takes place. Then it produced another error:
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgomp
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lrt
collect2: ld returned 1 exit status
I don't have a good understanding of how compilers exactly work. I tried to update all mingw-w64 compilers that I could find with apt-cache search but nothing helped. I have no idea what more I can do :(.
First, #nmaier is completely correct in that the Ubuntu x86_64-w64-mingw32 toolchain is crippled, and that you can rebuild the toolchain yourself.
I, however, suggest that you use MXE, which saves you the time of manually compiling gcc and every dependency of it. The steps below should be enough for your purpose:
# Get MXE
git clone https://github.com/mxe/mxe.git && cd mxe
# Settings
cat <<EOF > settings.mk
MXE_TARGETS := x86_64-w64-mingw32.static
JOBS := 4
EOF
# Build gcc, libgomp, blas, and cblas. It will take a while
make -j2 libgomp cblas
# Add toolchain to PATH
# See http://htmlpreview.github.io/?https://github.com/mxe/mxe/blob/master/index.html#tutorial step 4
export PATH=`pwd`/usr/bin:$PATH
# You don't need -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a
# because headers and libraries are installed to standard location and
# I already used `-lcblas -lblas`.
x86_64-w64-mingw32-g++ a.cpp b.cpp -fopenmp -O3 -o res.exe -lcblas -lblas -lgfortran -lquadmath
Your x86_64-w64-mingw32 toolchain appears to have been build without libgomp.
You could check your supplier/distribution if it there additional or variant packages that have libgomp.
Or switch to a different supplier/distribution.
Or you could rebuild (or build in the first place) a cross gcc with --enable-libgomp. This is kinda the hard way.
PS:
Adding paths that do not correspond with your platform, like -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include, is a bad idea in general, and will most certainly fail... This kinda creates a Franken-compiler.