I have the arm-none-linux-gnueabi-g++ compiler in the below path,
root#user-VirtualBox:~# which arm-none-linux-gnueabi-g++
/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-g++
and I have given the same in DCMAKE_COMPILER path in the build command of paho,
user#user-VirtualBox:~/octane_etk_sample-6.0.0.240/paho.mqtt.c$ cmake -Bbuild -H. -DPAHO_WITH_SSL=OFF -DPAHO_ENABLE_TESTING=OFF -DCMAKE_C_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-gcc -DCMAKE_CXX_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-g++
-- The C compiler identification is GNU 4.8.1
-- Check for working C compiler: /home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-gcc
-- Check for working C compiler: /home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version: 3.10.2
-- CMake system name: Linux
-- Timestamp is 2020-04-17T07:33:49Z
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_CXX_COMPILER
-- Build files have been written to: /home/user/octane_etk_sample-6.0.0.240/paho.mqtt.c/build
After this build I have given,
$ sudo cmake --build build/ --target install
$ sudo ldconfig
and I have copied libpaho-mqtt3c.so, libpaho-mqtt3c.so.1, libpaho-mqtt3c.so.1.3.1 from "/home/user/octane_etk_sample-6.0.0.240/paho.mqtt.c/build/src/" to the same folder where this "-lltkcpp_atmel" resides.
Whereas, when I give make it says, cannot find -lpaho-mqtt3c,
root#user-VirtualBox:/home/user/octane_etk_sample-6.0.0.240# make arm
mkdir -p ./bin
arm-none-linux-gnueabi-g++ \
-Wno-write-strings \
-Iinclude \
speedway_embedded_example.cpp -lpaho-mqtt3c \
-Llib \
-static -lltkcpp_atmel -lltkcppimpinj_atmel -lxml2_atmel \
-lssl_atmel -lcrypto_atmel -ldl_atmel \
-o bin/speedwayr_arm
/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lpaho-mqtt3c
How to overcome this issue? Is it something wrong while building the paho against arm-none-linux-gnueabi-gcc & g++?
Note 1:
Compiler command suggested by David Ranieri
root#user-VirtualBox:/home/mindlogic/octane_etk_sample-6.0.0.240# make arm
mkdir -p ./bin
arm-none-linux-gnueabi-g++ \
-Wno-write-strings \
-o bin/speedwayr_arm \
-Iinclude \
speedway_embedded_example.cpp -lpaho-mqtt3c \
-Llib \
-static -lltkcpp_atmel -lltkcppimpinj_atmel -lxml2_atmel \
-lssl_atmel -lcrypto_atmel -ldl_atmel
/home/mindlogic/octane_etk-6.0.0.240/arm-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lpaho-mqtt3c
Note 2:
I have changed the cmake build from
cmake -Bbuild -H. -DPAHO_WITH_SSL=OFF -DPAHO_ENABLE_TESTING=OFF -DCMAKE_C_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-gcc -DCMAKE_CXX_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-g++
to
cmake -Bbuild -H. -DPAHO_WITH_SSL=OFF -DPAHO_ENABLE_TESTING=OFF
-DPAHO_BUILD_STATIC=True -DCMAKE_C_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain/bin/arm-none-linux-gnueabi-gcc -DCMAKE_CXX_COMPILER=/home/user/octane_etk-6.0.0.240/arm-toolchain
After building a library as static one, now I can able to compile with "makr arm", successfully i.e., commands given below
root#user-VirtualBox:/home/user/octane_etk_sample-6.0.0.240# make cap
mkdir -p ./bin
arm-none-linux-gnueabi-g++ \
-Wno-write-strings \
-Iinclude \
speedway_embedded_example.cpp \
-Llib \
-static -lltkcpp_atmel -lltkcppimpinj_atmel -lxml2_atmel \
-lssl_atmel -lcrypto_atmel -ldl_atmel -lpaho-mqtt3c-static -ljansson -lpthread \
-o bin/speedwayr_arm
Order matters, try generating the object before linking:
arm-none-linux-gnueabi-g++ \
-Wno-write-strings \
-o bin/speedwayr_arm \
-Iinclude \
speedway_embedded_example.cpp -lpaho-mqtt3c \
-Llib \
-static -lltkcpp_atmel -lltkcppimpinj_atmel -lxml2_atmel \
-lssl_atmel -lcrypto_atmel -ldl_atmel
Related
Bit of a "hole in my bucket problem", here.
To start from the top, I was compiling musl-libc when I got an error claiming "can not be used when making a PIE object; recompile with -fPIE". It was pointing to some crto library that would have been packaged with gcc.
Okay, so...I assume I would have to recompile gcc at this point? That's fine, I'll give it a shot.
Except, now I'm running into this same error while trying to recompile gcc.
EDIT (The Error, or at least some of it):
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: gcov.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: json.o: relocation R_X86_64_32 against symbol `_ZTVN4json6objectE' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: hash-table.o: relocation R_X86_64_32S against symbol `prime_tab' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggc-none.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: libcommon.a(diagnostic.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
For ease, I've created a dockerfile that should reliably reproduce the error. The contents of the dockerfile are:
# docker build --rm --squash --tag gcc:dev -f ./Dockerfile
# docker run -it --rm --name gcc-dev gcc:dev
ARG JOBS=8
ARG CC=clang
ARG CXX=clang++
FROM alpine:edge as prep
ARG JOBS
ARG CC
ARG CXX
WORKDIR /root/work
RUN apk update && apk upgrade && apk add --no-cache make g++ clang
FROM prep AS gcc-build
ARG JOBS
ARG CC=gcc
ARG CXX=g++
ENV \
CFLAGS="-fpic -fPIE -fpie -static -static-libgcc" \
CXXFLAGS="-fpic -fPIE -fpie -static" \
LDFLAGS=""
ADD https://bigsearcher.com/mirrors/gcc/releases/gcc-10.2.0/gcc-10.2.0.tar.gz .
# COPY gcc/gcc-10.2.0.tar.gz .
RUN \
echo Adding gcc dependencies... && \
apk add gmp-dev mpfr-dev mpc1-dev isl-dev linux-headers && \
echo Building gcc... && \
echo Unpacking gcc... && \
tar zxf gcc-10.2.0.tar.gz && \
echo Moving gcc source files... && \
mv gcc-10.2.0/* . && rm -rf gcc-10.2.0 *.tar.gz && \
echo Configuring gcc... && \
./configure \
--build=x86_64-unknown-linux-musl \
--host=x86_64-unknown-linux-musl \
--target=x86_64-unknown-linux-musl \
# --prefix=/opt/gcc && \
--enable-languages=c,c++ \
--enable-default-pie \
--disable-shared \
--disable-nls \
--with-static-standard-libraries \
--with-stage1-ldflags="-static-pie" \
--with-boot-ldflags="-static-pie" \
--disable-multilib && \
time make -j${JOBS} bootstrap && \
apk del g++ gcc && \
make install
I had run into the error when leaving out the stage 1 -static-pie LDFLAGS. To make the error reproduce quickly, I've set the make target to bootstrap and included the stage 1 -static-pie LDFLAG, but I'm not totally convinced this is necessarily a good indicator of the nature of the error.
I will note that no matter what CFLAGS or CXXFLAGS I have, much of the bootstrapped and stage 2 gcc compilation occurs with something like the following command:
g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo insn-output.c
i.e. Its always passing the -fno-PIE flag. I would expect I need to get rid of that flag, but I can't find where I do such a thing.
So...how do I create a gcc package that I can use to create static PIE executables?
I got this to work but I had to compile basically the entire LLVM toolchain for x64 musl. Not sure if it ended up being compiler-rt, or libc++/libc++abi, but eventually I could bootstrap the LLVM toolchain using the -fPIE flag appropriately.
I've since given up on that entire endeavor. Its a nightmare trying to keep track of who's bootstraps are bootstrapping who's bootstraps.
I'm trying to build mkspiffs for windows. It's a c/c++ project. I installed mingw, and added it to my path.
The README.md says to run
$ git submodule update --init
$ make dist
The make dist command gives me the following output:
File not found - *.c
cc -std=gnu99 -Os -Wall -mno-ms-bitfields -Itclap -Iinclude -Ispiffs/src -I. -D VERSION=\"0.2.3-6-g983970e\" -D SPIFFS_VERSION=\"0.3.7-5-gf5e26c4\" -D BUILD_CONFIG=\"\" -D BUILD_CONFIG_NAME=\"-generic\" -D __NO_INLINE__ -c -o spiffs/src/spiffs_cache.o spiffs/src/spiffs_cache.c
process_begin: CreateProcess(NULL, cc -std=gnu99 -Os -Wall -mno-ms-bitfields -Itclap -Iinclude -Ispiffs/src -I. -D VERSION=\"0.2.3-6-g983970e\" -D SPIFFS_VERSION=\"0.3.7-5-gf5e26c4\" -D BUILD_CONFIG=\"\" -D BUILD_CONFIG_NAME=\"-generic\" -D __NO_INLINE__ -c -o spiffs/src/spiffs_cache.o spiffs/src/spiffs_cache.c, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [spiffs/src/spiffs_cache.o] Error 2
I'm using mingw64.
C:\Users\peterkapteyn>where gcc
C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\gcc.exe
I am a novice when it comes to building things from source/using makefiles and that sort of thing. Can anyone offer some insight into what's going on?
Using a Dockerfile, I'm attempting to build Clang version v8 along with its dependencies on Ubuntu 18.04. The reason I'm going through all this trouble is because I can't find a 32-bit version of the LLVM libraries. Even the LLVM packages themselves have only 64-bit variants of everything. Because of this, I'm not able to build my 32-bit applications using the LLVM toolchain at version 8. Using version 8 of LLVM is mandatory for reasons I won't go into here.
So far, here is what I have:
FROM ubuntu:18.04 AS build
ARG NUM_PARALLEL=8
RUN true \
&& dpkg --add-architecture i386 \
&& apt-get -qq update \
&& apt-get -qq install \
software-properties-common \
build-essential \
gcc-multilib \
g++-multilib \
git \
wget \
autoconf \
pkg-config \
m4 \
python-dev:i386 \
libcurl4-gnutls-dev:i386 \
libncurses-dev:i386 \
uuid-dev:i386 \
libx11-dev:i386 \
libxext-dev:i386 \
libtinfo-dev:i386 \
libedit-dev:i386 \
swig \
libedit-dev
python-dev
ENV CMAKE_BUILD_PARALLEL_LEVEL=$NUM_PARALLEL
# Ninja
RUN true \
&& git clone --depth 1 --branch v1.8.2 https://github.com/ninja-build/ninja.git \
&& cd ninja \
&& ./configure.py --bootstrap \
&& cp ninja /usr/local/bin
# CMake
RUN true \
&& git clone --depth 1 --branch v3.13.4 https://gitlab.kitware.com/cmake/cmake.git \
&& cd cmake \
&& ./bootstrap --parallel=$NUM_PARALLEL \
&& make -j$NUM_PARALLEL install
# Clang (See: https://clang.llvm.org/get_started.html)
RUN true \
&& git clone --depth 1 --branch llvmorg-8.0.0 https://github.com/llvm/llvm-project.git \
&& cd llvm-project \
&& cmake -G Ninja -B build -S llvm \
-D CMAKE_BUILD_TYPE=Release \
-D LLVM_BUILD_32_BITS:BOOL=ON \
-D LLVM_ENABLE_PROJECTS=all \
-D LLVM_BUILD_TESTS:BOOL=OFF \
-D LLVM_BUILD_EXAMPLES:BOOL=OFF \
-D LLVM_INCLUDE_EXAMPLES:BOOL=OFF \
-D LLVM_INCLUDE_TESTS:BOOL=OFF \
-D LLVM_INCLUDE_BENCHMARKS:BOOL=OFF \
&& cmake --build build -j $NUM_PARALLEL --target install
I get through compiling a little over 5200 translation units, which takes over an hour, only for it to fail:
[5232/6435] Linking CXX shared library lib/readline.so
FAILED: lib/readline.so
: && /usr/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -m32 -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -Wno-macro-redefined -O3 -DNDEBUG -Wl,-z,defs -Wl,-z,nodelete -m32 -shared -Wl,-soname,readline.so -o lib/readline.so tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/readline.cpp.o /usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libedit.so && :
/usr/lib/x86_64-linux-gnu/libpython2.7.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
I followed the getting started page to understand how to build LLVM so far, but I must be missing something. They don't exactly go into 32-bit compilation in their examples. Can someone help me get this building? Or at least (and probably better), point me to a version of Clang v8 that has 32-bit LLVM libraries bundled with it?
Seems like you are linking against the wrong Python: usr/lib/x86_64-linux-gnu/libpython2.7.so.
You may want to for it and add it to the CMake commands:
-DPYTHON_EXECUTABLE=PATH_TO_PYTHON-DEV:i686
You may also need to set PYTHON_LIBRARY and PYTHON_INCLUDE_DIR to make sure that the i386 versions are used.
I want to test a complex shared library (cxsc) with the help of cmake. After a lot of trial and error i managed to create a html coverage report but the lines I test, with the boost testing framework, are still red.
This is the script I use to create the coverage report:
rm -fr build_coverage
mkdir build_coverage
cd build_coverage
cmake \
-DCMAKE_BUILD_TYPE=Coverage \
..
make
cd ../tests
make clean
make
cd ../build_coverage
make cxsc_coverage
The cmake part where the coverage report gets created:
# Cleanup lcov
COMMAND ${LCOV_PATH} --zerocounters --directory ${CMAKE_CURRENT_SOURCE_DIR}/build_coverage/CMakeFiles/cxsc.dir/src
COMMAND ${LCOV_PATH} --capture --initial --no-external --directory ${CMAKE_CURRENT_SOURCE_DIR}/build_coverage/CMakeFiles/cxsc.dir/src --output-file ${_outputname}.before
# Run tests
COMMAND LD_LIBRARY_PATH=${CMAKE_CURRENT_SOURCE_DIR}/build_coverage ${_testrunner} ${ARGV3}
# Capturing lcov counters and generating report
COMMAND ${LCOV_PATH} --capture --no-checksum --no-external --directory ${CMAKE_CURRENT_SOURCE_DIR}/build_coverage/CMakeFiles/cxsc.dir/src --output-file ${_outputname}.after
COMMAND ${LCOV_PATH} --add-tracefile ${_outputname}.before --add-tracefile ${_outputname}.after --output-file ${_outputname}.info
COMMAND ${GENHTML_PATH} -o ${_outputname} ${_outputname}.info
Makefile of the test binary (I think this is where the error is):
g++ \
-o test_runner \
main.cpp \
test_interval.cpp \
-I./../src \
-I./../src/rts \
-I./../src/asm \
-I./../src/fi_lib \
-I./../build_coverage \
-L./../build_coverage \
-lcxsc \
-Wall -Winline \
-lboost_unit_test_framework
This is what happens:
cmake -DCMAKE_BUILD_TYPE=Coverage .. build_coverage directory is created with a target.dir directory and *.gcno files in it
cd tests && make Test executable is created and linked against the shared library in the build_coverage directory (Maybe here is my mistake)
make coverage Coverage data is collected and tests are executed
Edit:
To clarify my problem, there are some lines covered but only global consts or one helper function which is used pretty often. But not the functions/methods I call in my tests.
Files in build_coverage/CMakeFiles/cxsc.dir/src/:
After cmake -DC...: A few *.cmake and *.make files
After make in build_coverage dir: *.gcno files
After lcov -c -i ...: Still *.gcno files
After running tests: *.gcda and *.gcno files
After lcov -c ...: A lot of movement in the directory but still the same filenames
I don't see any gcov flags in your makefile. Try this one for test_runner :
g++ \
-Wall -Winline -fprofile-arcs -ftest-coverage \
main.cpp \
test_interval.cpp \
-I./../src \
-I./../src/rts \
-I./../src/asm \
-I./../src/fi_lib \
-I./../build_coverage \
-L./../build_coverage \
-lcxsc \
-lboost_unit_test_framework \
-lgcov \
-o test_runner
Your shared library need those flags too :
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage")
SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lgcov")
See this post with a similar problem.
NB : "--coverage" can substitute "-fprofile-arcs -ftest-coverage" and "-lgcov"
I've got a Stellaris Launchpad board with a Cortex M4F on it. I want to use FreeRTOS on the board with some of my own C++ code. FreeRTOS, however, is written in C so will not compile with G++; I've tried.
I read somewhere that I should compile FreeRTOS with gcc, then compile my application code with g++, then pull them together using the linker. This makes sense, but I'm really struggling with how to put this behaviour down in a Makefile. I found this Makefile which just confused me more.
Currently, I'm just using the Makefile distributed with the FreeRTOS example in the Stellaris demos, but that's set up for C code only. This question is asking something similar to what I'm after, but I can't wrap my head around how to compile FreeRTOS with GCC and the rest of my code with G++.
FreeRTOS apparently wraps it's code in extern "C" { } directives but attempting using G++ still fails when compiling the FreeRTOS codebase.
I don't like posting large amounts of code on SO, but the more information the better I suppose. The Stellaris demos have a common makedefs file:
# Get the operating system name. If this is Cygwin, the .d files will be
# munged to convert c: into /cygdrive/c so that "make" will be happy with the
# auto-generated dependencies.
os:=${shell uname -s}
# The compiler to be used.
ifndef COMPILER
COMPILER=gcc
endif
# Definitions for using GCC.
ifeq (${COMPILER}, g++)
# Get the prefix for the tools to use. Use arm-stellaris-eabi if it exists,
# otherwise fall back to arm-none-eabi.
PREFIX=${shell type arm-stellaris-eabi-gcc > /dev/null 2>&1 && \
echo arm-stellaris-eabi || echo arm-none-eabi}
# The command for calling the compiler.
CC=${PREFIX}-${COMPILER}
# The location of the C compiler
# ARMGCC_ROOT is used by some makefiles that need to know where the compiler
# is installed. It is not used further for normal stellarisware apps
ARMGCC_ROOT:=${shell dirname '${shell sh -c "which ${CC}"}'}/..
# Determine the compiler CPU/FPU options based on the processor variant.
ifndef VARIANT
CPU=-mcpu=cortex-m3
FPU=
else
ifeq (${VARIANT}, cm3)
CPU=-mcpu=cortex-m3
FPU=
else
ifeq (${VARIANT}, cm4f)
CPU=-mcpu=cortex-m4
FPU=-mfpu=fpv4-sp-d16 -mfloat-abi=softfp
else
$(error Unknown processor variant ${VARIANT}!)
endif
endif
endif
# The flags passed to the assembler.
AFLAGS=-mthumb \
${CPU} \
${FPU} \
-MD
# The flags passed to the compiler.
CFLAGS=-mthumb \
${CPU} \
${FPU} \
-Os \
-ffunction-sections \
-fdata-sections \
-MD \
-Wall \
-pedantic \
-DPART_${PART} \
-c
# The command for calling the library archiver.
AR=${PREFIX}-ar
# The command for calling the linker.
LD=${PREFIX}-ld
# The flags passed to the linker.
LDFLAGS=--gc-sections
# Get the location of libgcc.a from the GCC front-end.
LIBGCC=${shell ${CC} ${CFLAGS} -print-libgcc-file-name}
# Get the location of libc.a from the GCC front-end.
LIBC=${shell ${CC} ${CFLAGS} -print-file-name=libc.a}
# Get the location of libm.a from the GCC front-end.
LIBM=${shell ${CC} ${CFLAGS} -print-file-name=libm.a}
# The command for extracting images from the linked executables.
OBJCOPY=${PREFIX}-objcopy
# Tell the compiler to include debugging information if the DEBUG environment
# variable is set.
ifdef DEBUG
CFLAGS+=-g -D DEBUG
endif
# Add the tool specific CFLAGS.
CFLAGS+=${CFLAGSgcc}
# Add the include file paths to AFLAGS and CFLAGS.
AFLAGS+=${patsubst %,-I%,${subst :, ,${IPATH}}}
CFLAGS+=${patsubst %,-I%,${subst :, ,${IPATH}}}
# The rule for building the object file from each C source file.
${COMPILER}${SUFFIX}/%.o: %.c
#if [ 'x${VERBOSE}' = x ]; \
then \
echo " CC ${<}"; \
else \
echo ${CC} ${CFLAGS} -D${COMPILER} -o ${#} ${<}; \
fi
#${CC} ${CFLAGS} -D${COMPILER} -o ${#} ${<}
ifneq ($(findstring CYGWIN, ${os}), )
#sed -i -r 's/ ([A-Za-z]):/ \/cygdrive\/\1/g' ${#:.o=.d}
endif
# The rule for building the object file from each assembly source file.
${COMPILER}${SUFFIX}/%.o: %.S
#if [ 'x${VERBOSE}' = x ]; \
then \
echo " AS ${<}"; \
else \
echo ${CC} ${AFLAGS} -D${COMPILER} -o ${#} -c ${<}; \
fi
#${CC} ${AFLAGS} -D${COMPILER} -o ${#} -c ${<}
ifneq ($(findstring CYGWIN, ${os}), )
#sed -i -r 's/ ([A-Za-z]):/ \/cygdrive\/\1/g' ${#:.o=.d}
endif
# The rule for creating an object library.
${COMPILER}${SUFFIX}/%.a:
#if [ 'x${VERBOSE}' = x ]; \
then \
echo " AR ${#}"; \
else \
echo ${AR} -cr ${#} ${^}; \
fi
#${AR} -cr ${#} ${^}
# The rule for linking the application.
${COMPILER}${SUFFIX}/%.axf:
#if [ 'x${SCATTERgcc_${notdir ${#:.axf=}}}' = x ]; \
then \
ldname="${ROOT}/${COMPILER}/standalone.ld"; \
else \
ldname="${SCATTERgcc_${notdir ${#:.axf=}}}"; \
fi; \
if [ 'x${VERBOSE}' = x ]; \
then \
echo " LD ${#} ${LNK_SCP}"; \
else \
echo ${LD} -T $${ldname} \
--entry ${ENTRY_${notdir ${#:.axf=}}} \
${LDFLAGSgcc_${notdir ${#:.axf=}}} \
${LDFLAGS} -o ${#} $(filter %.o %.a, ${^}) \
'${LIBM}' '${LIBC}' '${LIBGCC}'; \
fi; \
${LD} -T $${ldname} \
--entry ${ENTRY_${notdir ${#:.axf=}}} \
${LDFLAGSgcc_${notdir ${#:.axf=}}} \
${LDFLAGS} -o ${#} $(filter %.o %.a, ${^}) \
'${LIBM}' '${LIBC}' '${LIBGCC}'
#${OBJCOPY} -O binary ${#} ${#:.axf=.bin}
endif
The above file is included by the Makefile itself (below):
# Defines the part type that this project uses.
PART=LM4F120H5QR
# Set the processor variant.
VARIANT=cm4f
# The base directory for StellarisWare.
ROOT=../lib
COMPILER=gcc
# Include the common make definitions.
include ${ROOT}/makedefs
# Where to find source files that do not live in this directory.
VPATH=${ROOT}/FreeRTOS/Source/portable/GCC/ARM_CM4F
VPATH+=${ROOT}/FreeRTOS/Source/portable/MemMang/
VPATH+=${ROOT}/FreeRTOS/Source
VPATH+=${ROOT}/drivers
VPATH+=${ROOT}/utils
# Where to find header files that do not live in the source directory.
IPATH=.
IPATH+=..
IPATH+=${ROOT}
IPATH+=${ROOT}/FreeRTOS/Source/portable/GCC/ARM_CM4F
IPATH+=${ROOT}/FreeRTOS
IPATH+=${ROOT}/FreeRTOS/Source/include
IPATH+=${ROOT}
# The default rule, which causes the FreeRTOS example to be built.
all: ${COMPILER}
all: ${COMPILER}/freertos_demo.axf
# The rule to clean out all the build products.
clean:
#rm -rf ${COMPILER} ${wildcard *~}
# The rule to create the target directory.
${COMPILER}:
#mkdir -p ${COMPILER}
# Rules for building the FreeRTOS example.
${COMPILER}/freertos_demo.axf: ${COMPILER}/buttons.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/freertos_demo.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/heap_2.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/led_task.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/list.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/port.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/queue.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/rgb.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/startup_${COMPILER}.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/switch_task.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/tasks.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/uartstdio.o
${COMPILER}/freertos_demo.axf: ${COMPILER}/ustdlib.o
${COMPILER}/freertos_demo.axf: ${ROOT}/driverlib/${COMPILER}-cm4f/libdriver-cm4f.a
${COMPILER}/freertos_demo.axf: freertos_demo.ld
SCATTERgcc_freertos_demo=freertos_demo.ld
ENTRY_freertos_demo=ResetISR
CFLAGSgcc=-DTARGET_IS_BLIZZARD_RA1
# Include the automatically generated dependency files.
ifneq (${MAKECMDGOALS},clean)
-include ${wildcard ${COMPILER}/*.d} __dummy__
endif
Some of my directory structure is as follows:
Projects/
lib/
FreeRTOS/
driverlib/
drivers/
inc/
utils/
makedefs
TestProject/
loads.cpp
of.cpp
files.h
here.h
Makefile
If I'm correct in saying that FreeRTOS must be compiled with GCC, then linked with my C++ project code, how can I modify my current Makefile to do that? I want a reasonably generic solution so I can re-use it in other projects, but I don't know much about the C/C++ build process or Makefiles, hence me asking this (lengthy) question. I don't want/mean to sound like I'm asking a "do this for me" question, but I really cannot work out how to do this despite searching on Google and on SO.
I don't use FreeRTOS with C++ myself, but it has been discussed many times on the FreeRTOS forum and there are a few C++ frameworks in the FreeRTOS Interactive site.