I am using GNU MCU ECLIPSE and the ARM toolchain to target CortexM MCUs, and I want to use functions from CMSIS DSP library.
I have downloaded the library from the repository from https://github.com/ARM-software/CMSIS_5, added to the compiler settings the paths to the includes, and in the linker options I have added the folder C:/workspace/CMSIS/DSP/Lib/GCC as path to search for libraries, and added 'arm_cortexM3l_math' to the libraries.
When I try to build I get the error
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -Xlinker --gc-sections -L"C:\workspace\eclipse_tools\CMSIS_5-develop\CMSIS\DSP\Lib\GCC" -Wl,-Map,"hello6.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group -o "hello6.elf" ./src/main.o -larm_cortexM3l_math
c:/workspace/eclipse_tools/arm embedded gcc/8.2.1-1.7-20190524-0603/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe:C:\workspace\eclipse_tools\CMSIS_5-develop\CMSIS\DSP\Lib\GCC\libarm_cortexM3l_math.a: file format not recognized; treating as linker script
c:/workspace/eclipse_tools/arm embedded gcc/8.2.1-1.7-20190524-0603/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe:C:\workspace\eclipse_tools\CMSIS_5-develop\CMSIS\DSP\Lib\GCC\libarm_cortexM3l_math.a:1: syntax error
I don't understand why can't the linker read the library in .a format. I have tried with a clean eclipse installation both on windows and linux and with both the GNU MCU Eclipse ARM Embedded GCC and the GNU ARM Embedded Toolchain.
Build tools for windows are also correctly installed.
I realized that, despite those files look like libraries, they were kind of a placeholder, as they were just few bytes. I then downloaded and unpacked the CMSIS packs from here:
https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-packs
(Submenu ARM->CMSIS)
and the same files now work.
So I guess they were not compiled yet? But there was no makefile in the repository, how was I supposed to build them?
#andy mango, thanks, the file command indeed returned just 'ASCII text file'
Related
I am using mingw 64 bit with cygwin.
I know that if I compile using
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp
the output .exe does not run unless the library path to libstdc++ and other libraries is specified in the Path environment variable.
An alternative is to link statically
x86_64-w64-mingw32-g++.exe -std=c++11 hello.cpp -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread
Since I want a single .exe that I can easily copy on different machines, the second solution is better for me. My only problem is that, since I link statically, even for a simple helloworld program, the size of the executable rises to more than 10 Mb. So my question is: is it possible to link statically only the library parts that are actually used by the program?
The binutils linker on Windows, ld, does not support the --gc-sections argument properly, which in combination with compiler flags -ffunction-sections and -fdata-sections, allow the linker to throw away blocks of unused code.
You are straight out of luck. The only thing you can do is the usual: strip the executable (by running the strip command on it after it is linked) and compile your code optimising for size with -Os.
Keeping in mind these options do not work on Windows (which for the purpose of this answer, includes the Cygwin platform), this is generally how you can do this:
g++ -c -Os -ffunction-sections -fdata-sections some_file.cpp -o some_file.o
g++ -c -Os -ffunction-sections -fdata-sections main.cpp -o main.o
g++ -Wl,--gc-sections main.o some_file.p -o my_executable
I am trying to use libjpeg in my jni program on Ubuntu. I built my c++ code with g++, with libjpeg added as a library. I tried both linking the shared version and the static version, but both of them cause "undefined symbol: jpeg_std_error" error in Java (while my c++ codes worked fine). I did use "extern "C"" for the libjpeg header.
Here is my build script with static libjpeg.a (libjpeg built as part of libjpeg-turbo and renamed libjpeg151.a):
outputName=$libDir/libMyLib.so
g++ -DNDEBUG -O3 -march=native -mfpmath=sse -Ofast -flto -funroll-loops -fPIC -w -shared -o $outputName \
-I$jdkDir/include -I$jdkDir/include/linux -std=c++11 -pthread \
-L$libDir/SEngineLibraries/libjpegTurbo151Linux -ljpeg151 \
myCode.cpp
and the one with shared version (with libjpeg-turbo deb installed)
outputName=$libDir/libMyLib.so
g++ -DNDEBUG -O3 -march=native -mfpmath=sse -Ofast -flto -funroll-loops -fPIC -w -shared -o $outputName \
-I$jdkDir/include -I$jdkDir/include/linux -std=c++11 -pthread \
-ljpeg \
myCode.cpp
In my Java code, when running to codes using libjpeg, this error pops out:
symbol lookup error: /myDir/lib/libMyLib.so: undefined symbol: jpeg_std_error
Here is something might be suspicious: no matter I include the line referencing libjpeg in the build script or not, the .so library has a constant size.
It is strange that it doesn't work with the static version of the library, because then there should not be an extra linked jpeg lib. Few options which you can try:
specify -Wl,--no-undefined to print error for undefined references in the .so (by default the linker doesn't fail when shared library has unresolved symbols)
try ldd <sharedlib> to see unresolved dependencies
for shared library linking, try adding RPATH: -Wl,-rpath,/path/to/jpeglib_so_dir - this inserts the path to the libjpeg.so inside the shared library so that it can be resolved without being in the ldd path
I have a C++ project which i've been working on for a while. I decided to import it into eclipse mainly for code-completion/parsing and visual-debugging.
The project uses a makefile, and g++ compiler.
The relevant flags i pass to g++ are:
LOCAL_CPPFLAGS = -g -O0 -Wall -Wextra -rdynamic -DPLATFORM_DESKTOP -DDEBUG -std=c++11
LIB_FLAGS = -lglfw -lGL -lGLU -lGLEW -lpthread -lXxf86vm ./Libraries/libpng/built/libpng14.a -lz
I can debug the executable from the command line just fine. But when i try to set up a debug configuration in eclipse it seems to always break in a certain _dl_debug_state() with no symbols available (regardless of whether or not i have any breakpoints set)
When i turn on verbose logging i think i see it is in a shared library: /lib64/ld-linux-x86-64.so.2
I tried importing just the executable into a debug configuration, and that had the same result.
I read other questions in here and other forums which seemed to deal with the same issue, but none of them worked for me.
Ok, fixed it.
In the Debug-configuration, under the "Debugger" tab, there is a "Shared Libraries" sub-tab. Unchecking "Load shared library symbols automatically" helped.
Basically, i could see in the verbose output that it was doing some things with "auto-solib-add" and "stop-on-solib-event" , but the sub-tab was kind of hidden and i didn't find it quickly enough in my meddling.
In the CImg Makefile I notice a flag "-lm" I think this points to the m.lib file. But for some reason it cannot find it during the Linking phase. I am compiling the code using the following command:
nvcc -o FilledTriangles FilledTriangles.cu -I.. -O2 -lm -lgdi32
"nvcc" is just the nvidia CUDA compiler. It should function similar to g++
-lm refers to "libm.so"
In general, -lXYZ is a way of telling the linker that it should resolve the symbols in your compiled code against libXYZ.so (after locating it, usually in /usr/lib).
i'm trying to develop for the BeagleBoard.
Therefore i installed the CodeSourcery Sourcery_G++_Lite Toolchain.
I want to use the opencv library. So I downloaded the sources to my Ubuntu devolepment system, compiled with gcc as shared library and installed the library.
When i build a helloworld-application for the x86-Architecture, everything is fine.
Now, i want to compile the same application with the other toolchain for the ARM-Architecture.
I get these warnings/erros while compiling/linking:
john#ubuntu:~/Downloads/BeagleTest$ arm-none-linux-gnueabi-g++ -c ImageProcessing.cpp -o ImageProcessing.o -I/usr/local/include
cc1plus: warning: include location "/usr/local/include" is unsafe for cross-compilation
john#ubuntu:~/Downloads/BeagleTest$ arm-none-linux-gnueabi-g++ -c Main.cpp -o Main.o -I/usr/local/include
cc1plus: warning: include location "/usr/local/include" is unsafe for cross-compilation
john#ubuntu:~/Downloads/BeagleTest$ arm-none-linux-gnueabi-g++ -oApplication -L/usr/local/lib Main.o ImageProcessing.o -lopencv_core
/usr/local/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/usr/local/lib" is unsafe for cross-compilation
/usr/local/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/lib/libopencv_core.so when searching for -lopencv_core
/usr/local/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lopencv_core
collect2: ld returned 1 exit status
Obviously, im using the same include-directories and library-pathes like im using for the x86-Architecture. This does not work. But what do i have to do? Do i have to cross compile the opencv-library?
Libraries have to be cross compiled and you have to make sure the correct library is found when linking. If that shouldn't work automatically you may want to take a look at the --sysroot command line switch of gcc.
Yes. Libraries are specific to an architecture.