Yocto Hello World C++ CMake Project is not able to compile a simple test program - eclipse

I'm failing to build the simple Hello World C++ CMake Project in Eclipse with Yocto plugin. Yocto's version is "thud".
The local.conf have the line:
TOOLCHAIN_HOST_TASK_append += " nativesdk-cmake"
I've build the sdk
bitbake myBoard -c populate_sdk
I've installed the sdk, sourced the enviroment setup, launched eclipse from the same terminal and configured the yocto plugin.
The enviroment script have the following variable:
export SDKTARGETSYSROOT=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
export CC="arm-fslc-linux-gnueabi-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
export CXX="arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
export CPP="arm-fslc-linux-gnueabi-gcc -E -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
When I try to build I have the following output (even sourcing the sdk's enviroment setup and then cmake from command line):
$ cmake ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-gcc
-- Check for working C compiler: /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-gcc -- broken
CMake Error at /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /yocto/eclipse-ws/prova/Debug/CMakeFiles/CMakeTmp
Run Build Command:"/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/bin/make" "cmTC_4df0b/fast"
/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/bin/make: 1: /yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/bin/make: Syntax error: word unexpected (expecting ")")
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:4 (PROJECT)
-- Configuring incomplete, errors occurred!
See also "/yocto/eclipse-ws/prova/Debug/CMakeFiles/CMakeOutput.log".
See also "/yocto/eclipse-ws/prova/Debug/CMakeFiles/CMakeError.log".
Someone see something wrong or missing that is causing the error?
Thank you in advance for any help
Update
The CMakeOutput.log show:
The system is: Linux - 4.15.0-47-generic - x86_64
Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded.
Compiler: /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-gcc
Build flags: ;;;--sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi;;-march=armv7-a;-mthumb;-mfpu=neon;-mfloat-abi=hard;
Id flags:
The output was:
0
Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "a.out"
The C compiler identification is GNU, found in "/yocto/eclipse-ws/prova/Debug/CMakeFiles/3.12.2/CompilerIdC/a.out"
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/arm-fslc-linux-gnueabi/arm-fslc-linux-gnueabi-g++
Build flags: ;;;--sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi;;-march=armv7-a;-mthumb;-mfpu=neon;-mfloat-abi=hard;;-fpermissive
Id flags:
The output was:
0
Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "a.out"
The CXX compiler identification is GNU, found in "/yocto/eclipse-ws/prova/Debug/CMakeFiles/3.12.2/CompilerIdCXX/a.out"
Update 2
If I remove everything from the Debug folder and run cmake from command line I have a success and I can build even in Eclipse. If I change something in CMakeLists.txt then the error show up again.
I see that Debug/CMakeFiles/3.12.2/CMakeSystem.cmake is different when it is generated by eclipse or by command line:
Eclipse)
set(CMAKE_HOST_SYSTEM "Linux-4.15.0-47-generic")
set(CMAKE_HOST_SYSTEM_NAME "Linux")
set(CMAKE_HOST_SYSTEM_VERSION "4.15.0-47-generic")
set(CMAKE_HOST_SYSTEM_PROCESSOR "x86_64")
include("/yocto/eclipse-ws/prova/toolchain.cmake")
set(CMAKE_SYSTEM "Linux-4.15.0-47-generic")
set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_VERSION "4.15.0-47-generic")
set(CMAKE_SYSTEM_PROCESSOR "x86_64")
set(CMAKE_CROSSCOMPILING "FALSE")
set(CMAKE_SYSTEM_LOADED 1)
Command Line)
set(CMAKE_HOST_SYSTEM "Linux-4.15.0-47-generic")
set(CMAKE_HOST_SYSTEM_NAME "Linux")
set(CMAKE_HOST_SYSTEM_VERSION "4.15.0-47-generic")
set(CMAKE_HOST_SYSTEM_PROCESSOR "x86_64")
include("/yocto/sdk/aw70pc_am8000/sysroots/x86_64-fslcsdk-linux/usr/share/cmake/OEToolchainConfig.cmake")
set(CMAKE_SYSTEM "Linux")
set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_VERSION "")
set(CMAKE_SYSTEM_PROCESSOR "armv7at2hf-neon-fslc")
set(CMAKE_CROSSCOMPILING "TRUE")
set(CMAKE_SYSTEM_LOADED 1)
From what I understand the eclipse plugin is generating a configuration that use the arm toolchain to compile a test program, not crosscompiling, and obviously it fail. Cmake from command line instead generate it the right way but it's overwritten by the first change in eclipse.
Here's the printenv as requested by danlor
ARCH=arm
CONFIG_SITE=/yocto/sdk/myBoard/site-config-armv7at2hf-neon-fslc-linux-gnueabi
SDKTARGETSYSROOT=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
KCFLAGS=--sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
OECORE_ACLOCAL_OPTS=-I /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/share/aclocal
CC=arm-fslc-linux-gnueabi-gcc -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
OECORE_DISTRO_VERSION=2.6
OECORE_SDK_VERSION=2.6.1
PKG_CONFIG_SYSROOT_DIR=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
STRIP=arm-fslc-linux-gnueabi-strip
OBJCOPY=arm-fslc-linux-gnueabi-objcopy
CONFIGURE_FLAGS=--target=arm-fslc-linux-gnueabi --host=arm-fslc-linux-gnueabi --build=x86_64-linux --with-libtool-sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
OECORE_NATIVE_SYSROOT=/yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux
RANLIB=arm-fslc-linux-gnueabi-ranlib
OBJDUMP=arm-fslc-linux-gnueabi-objdump
AS=arm-fslc-linux-gnueabi-as
AR=arm-fslc-linux-gnueabi-ar
TARGET_PREFIX=arm-fslc-linux-gnueabi-
NM=arm-fslc-linux-gnueabi-nm
CXX=arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
OECORE_TARGET_OS=linux-gnueabi
OECORE_TARGET_ARCH=arm
OECORE_TARGET_SYSROOT=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
CROSS_COMPILE=arm-fslc-linux-gnueabi-
OE_CMAKE_TOOLCHAIN_FILE=/yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/share/cmake/OEToolchainConfig.cmake
CPPFLAGS=
LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
OE_CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX=
OECORE_BASELIB=lib
PKG_CONFIG_PATH=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/pkgconfig:/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/share/pkgconfig
CPP=arm-fslc-linux-gnueabi-gcc -E -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
LD=arm-fslc-linux-gnueabi-ld --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi
toolchain.cmake
# CMake system name must be something like "Linux".
# This is important for cross-compiling.
set(CMAKE_SYSTEM_PROCESSOR )
set(CMAKE_C_COMPILER arm-fslc-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER arm-fslc-linux-gnueabi-g++)
set(CMAKE_C_FLAGS " --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard " CACHE STRING "CFLAGS")
set(CMAKE_CXX_FLAGS " --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -fpermissive" CACHE STRING "CXXFLAGS")
set(CMAKE_C_FLAGS_RELEASE " --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -DNDEBUG" CACHE STRING "CFLAGS for release")
set(CMAKE_CXX_FLAGS_RELEASE " --sysroot=/yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -DNDEBUG" CACHE STRING "CXXFLAGS for release")
set(CMAKE_C_LINK_FLAGS "" CACHE STRING "LDFLAGS")
set(CMAKE_CXX_LINK_FLAGS "" CACHE STRING "LDFLAGS")
# only search in the paths provided so cmake doesnt pick
# up libraries and tools from the native build machine
set(CMAKE_FIND_ROOT_PATH /yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux /yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi )
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
# Use qt.conf settings
set(ENV{QT_CONF_PATH} qt.conf)
# We need to set the rpath to the correct directory as cmake does not provide any
# directory as rpath by default
set(CMAKE_INSTALL_RPATH )
# Use native cmake modules
set(CMAKE_MODULE_PATH /cmake/Modules/)
# add for non /usr/lib libdir, e.g. /usr/lib64
set(CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
Workaround
I've found a way out
Adding the following 2 lines in CMakeLists.txt will tell cmake that the compiler works and to not test it
SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
Now I can build successfully my own program and it works like a charm.
It means that Eclipse can crosscompile my program but when checking the system it build the test program in a different way.

It seems that you're trying to use the cross-compiled make tool (the one that is compiled for your TARGET, i.e. /yocto/sdk/myBoard/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/bin/make) instead of the HOST make tool (/yocto/sdk/myBoard/sysroots/x86_64-fslcsdk-linux/usr/bin/make). Change it and try again :)

Related

requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC

I'm building a gst-plugin through yocto 1.6. I've linaro 4.9 cross toolchain of 32 and 64-bit.
When I'm building the plugin using 64-bit toolchain, it was success ( I got the plugin .so file) whereas if I build the same source using 32-bit toolchain I got the below error
/home/build-directory/tmp/sysroots/x86_64-linux/usr/libexec/cortexa8hf-vfp-neon-rdk-linux-gnueabi/gccgcc/arm-rdk-linux-gnueabi/4.9.4/ld: error: .libs/libgstpluginxxx_la-gstpluginxxx.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
here the whole error
./arm-rdk-linux-gnueabi-libtool --tag=CC --tag=disable-static --mode=link arm-rdk-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -fno-omit-frame-pointer -fno-optimize-sibling-calls --sysroot=/home/sysroots/path -pthread -I/home/sysroots/path/usr/include/gstreamer-1.0 -I/home/sysroots/path/usr/include/glib-2.0 -I/home/sysroots/path/usr/lib/glib-2.0/include -O2 -pipe -g -feliminate-unused-debug-types -fPIC -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o libgstpluginxxx.la -rpath /usr/lib/gstreamer-1.0 libgstpluginxxx_la-gstpluginxxx.lo -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
arm-rdk-linux-gnueabi-libtool: link: arm-rdk-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -enable-shared -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 -fno-omit-frame-pointer -fno-optimize-sibling-calls --sysroot=/home/sysroots/path -shared -fPIC -DPIC .libs/libgstpluginxxx_la-gstpluginxxx.o /home/sysroots/path/usr/lib/libgstreamer-1.0.so -L/home/sysroots/path/usr/lib /home/sysroots/path/usr/lib/libgmodule-2.0.so -lm -ldl /home/sysroots/path/usr/lib/libgobject-2.0.so /home/sysroots/path/usr/lib/libffi.so /home/sysroots/path/usr/lib/libglib-2.0.so -lpthread -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/home/sysroots/path -pthread -O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -pthread -Wl,-soname -Wl,libgstpluginxxx.so.0 -o .libs/libgstpluginxxx.so.0.0.0
/home/build-directory/tmp/sysroots/x86_64-linux/usr/libexec/cortexa8hf-vfp-neon-rdk-linux-gnueabi/gcc/arm-rdk-linux-gnueabi/4.9.4/ld: error: .libs/libgstpluginxxx_la-gstpluginxxx.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
I was confused, why the build was failed to recompile with -fPIC though it was mentioned in the linking command? I tried -fPIC option manually everywhere in the Makefile and libtool script, but no use :(
and
without modifying the source and recipe file, it was success in 32-bit toolchain whereas failed in 64-bit toolchain and telling to recompile with -fPIC option
Below are the build machine info.
BB_VERSION = "1.28.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Ubuntu-14.04"
This is likely a bug in gold linker. similar to
https://sourceware.org/ml/binutils/2010-12/msg00473.html
It seems you are using gold linker as default ld. So please pass
LDFLAGS += "-fuse-ld=bfd"
in recipe for this package. and see if that helps. This will force GNU BFD linker to be used for this package.
I was confused, why the build was failed to recompile with -fPIC though it was mentioned in the linking command? I tried -fPIC option manually everywhere in the Makefile and libtool script, but no use :(
Regarding these statements...
make distclean should clean all artifacts so everything gets rebuilt. You will also need to reconfigure.
Before you reconfigure, open your configure.ac and be sure you have a LT_INIT that includes pic-only:
AC_INIT([Crypto++], [8.3], ...)
LT_INIT([pic-only,enable-shared,enable-static])
AM_INIT_AUTOMAKE
...

Compiling Freetype 2.6.5 Xcode for IOS

Alright guys, I posted a similar question and took it down because it wasn't specific enough so here I go. From the zip file of Freetype 2.6.5 I have not been able to create an Xcode project that will compile the library for iOS use, only for i386_64.
I tried the commands here but I don't get past the first commands the and I am getting this
FreeType build system -- automatic system detection
The following settings are used:
platform unix compiler cc
configuration directory ./builds/unix configuration rules
./builds/unix/unix.mk
If this does not correspond to your system or settings please remove
the file `config.mk' from this directory then read the INSTALL file
for help.
Otherwise, simply type
/Applications/Xcode.app/Contents/Developer/usr/bin/make' again to
build the library, or
/Applications/Xcode.app/Contents/Developer/usr/bin/make refdoc' to
build the API reference (this needs python >= 2.6).
cd builds/unix; \
./configure 'CFLAGS=-arch i386' /bin/sh: ./configure: No such file or directory make: *** [setup] Error 127
I also followed the instructions inside the cmakelists.txt that it comes inside the project but still nothing, I still get an xcode project for osx and not for IOS which is giving me a plethora of linking errors. Here is the instructions for your reference.
For an iOS static library, use
#
cmake -D IOS_PLATFORM=OS -G Xcode
#
or
#
cmake -D IOS_PLATFORM=SIMULATOR -G Xcode
I am not sure what else to do. Any help?
Here's an outline of the basic build process to compile the FreeType libaries for iOS:
Download the latest FreeType source code
Extract the archive and cd into the unarchived directory
Setup toolchain and export variables for the architectures desired (arm64, arm7, i386, x86_64)
Compile the source code and build the libraries
For example, the build commands for arm64 might look something like this:
$ export CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
$ iphoneos="7.0" # target version of iOS
$ ARCH="arm64" # architecture (arm64, arm7, i386, x86_64)
$ export CFLAGS="-arch ${ARCH} -pipe -mdynamic-no-pic -Wno-trigraphs -fpascal-strings \
-O2 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden \
-miphoneos-version-min=$iphoneos -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/libxml2 \
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk"
$ export AR="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"
$ export LDFLAGS="-arch ${ARCH} -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk \
-miphoneos-version-min=7.0"
$ ./configure --host="aarch64-apple-darwin" --enable-static=yes --enable-shared=no
$ make
$ clean
It's a bit of work to construct the commands for each arch, but
fortunately there's a build
script
— which automatically downloads, extracts, and builds the latest FreeType (2.6.5 currently).
To run the script just use the following command in Terminal:
./build_freetype.sh
The resulting iOS libraries can be found in ~/Desktop/FreeType_iOS_Release when it completes.

redhat: netbeans: g++: compiler options applied to linker

I am using NetBeans under RedHat. I have a couple of open projects that combine together to make a command line executable and a shared object "plugin". There are two static libraries in the mix as well. That is all fine and good.
I just noticed that when I "clean and build" the executable and the shared object that the compiler options are also expressed on the linker line. a la:
g++ -O2 -Wall -c -fmessage-length=0 -c -g -Werror -DDEBUG -DDEBUG_2 -I/usr/include -I/usr/include/c++/4.4.7/x86_64-redhat-linux -I/usr/include/c++/4.4.7 -I../ITGUtilities -MMD -MP -MF "build/Debug/GNU-Linux-x86/LocalCache.o.d" -o build/Debug/GNU-Linux-x86/LocalCache.o LocalCache.cpp
then later in the compile line (edited for brevity):
g++ -O2 -Wall -c -fmessage-length=0 -fPIC -o dist/Debug/GNU-Linux-x86/pam_plugin.so build/Debug/GNU-Linux-x86/pam_plugin.o -L... -lpam -l... -shared -fPIC
g++: build/Debug/GNU-Linux-x86/pam_plugin.o: linker input file unused because linking not done
I think I have a fairly generic set of project configs. I did set the -O2 -Wall -c -fmessage-length=0 compiler options but there are no options supplied for the linker other than whatever defaults NetBeans applies.
For the executable and plugin projects I can go to Properties > Linker > Additional Options and expand the [...] to see what NB thinks it will apply. That does not show the compile options but doing an actual build does apply them.
It is not doing the link step and I am assuming that is because of the compiler options. This is weird.
ideas?
Do not add -c option to the compiler options which says not to run the linker. It will be added as needed when just compiling anyway.

Windows + Eclipse + ARM-GCC

I would like to use eclipse IDE for my development with Tiva (LM4F) processor. I did this tutorial. Kernel hacks tutorial.
I use Win 8.1 x64 + eclipse + ARM-GCC and I would like to program a LM4F MCU.
I sat up everything, compiler path, the driverlib path. But It can't find the correct dependencies
Invoking: Cross GCC Compiler
arm-none-eabi-gcc -DPART_LM4F120H5QR -DTARGET_IS_BLIZZARD_RA1 -DARM_MATH_CM4 -I../.. /../stellarisware/ -I../../../stellarisware/utils -I../../../stellarisware/driverlib -I../../../stellarisware/inc/ -O0 -g3 -Wall -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
c:/gnu_gcc_arm/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/softfp\libg.a(lib_a-exit.o): In function 'exit':
exit.c:(.text.exit+0x16): undefined reference to '_exit'
C:\Users\MTYS~1\AppData\Local\Temp\ccECjb0N.o: In function 'Init_Adc':
C:\eclipse_workspace\proba\Debug/../main.c:20: undefined reference to 'SysCtlPeripheralEnable'
And all of driver functions gave me error.
And my path is (windows path: C:\stellarisware\, the project folder is C:\eclipse_workspace\try):
../../../stellarisware/
../../../stellarisware/utils
../../../stellarisware/driverlib
../../../stellarisware/inc/
I tried different methods (use cygwin path, or absolute windows path), the code can be compiled successfully with IAR. What should I do?

How do I make eclipse acknowledge my include files in a C++ Existing Makefile project?

Simple question: I have a C++ project configured for a existing makefile and it compiles fine. However, the IDE keeps complaining that it cannot resolve most of my symbols.
How do I configure eclipse to use my includes?
Project->properties->C/C++ General->Paths and Symbol
Add the path to your include directory.
You can see in the screenshot, the configuration I use to develop with Qt in C++.
I added my includes in the paths and symbols, but they are not added during qt compilation.
For compilation, qt uses these includes and ignores what I've added:
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Idebug -I. -o debug/bp.o bp.cpp
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Idebug -I. -o debug/Navigation.o Navigation.cpp
Navigation.cpp:16:22: error: XnOpenNI.h: No such file or directory
Navigation.cpp:17:26: error: XnCppWrapper.h: No such file or directory
Navigation.cpp:18:20: error: XnHash.h: No such file or directory
Navigation.cpp:19:19: error: XnLog.h: No such file or directory
Navigation.cpp:22:16: error: cv.h: No such file or directory
Navigation.cpp:23:18: error: cv.hpp: No such file or directory
I found the answer here:
QT Eclipse Integration - Adding External Libs
It seems that this is a kind of conflict between the CDT and Qt builder, so even if you add the options in CDT as in the screenshot above, the compiler doesn't find them!
You need to add them in the xxx.pro file as this:
http://doc.qt.digia.com/4.5/qmake-variable-reference.html#includepath
I had the same problem when I imported an existing Makefile project with:
File -> New -> Makefile Project with Existing Code
If you don't want to configure anything and just want eclipse to recognize all Paths from your existing (working) Makefile on it's own just do the following:
right click on your project -> Clean Project
right click on your project -> Build Project
The Eclipse Indexer then recognizes all paths on it's own without needing any additional configuration. You just need Eclipse to execute your imported Makefile and everything is resolved (if your Makefile works properly outside Eclipse).
Tested in:
Eclipse IDE for C/C++ Developers
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600