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.
Related
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'
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 C++ app that uses Boost.Asio and OpenSSL.
I try to build app in Ubuntu 16.04 and I am stucked.
All .cpp files compiled correctly. Compilation flags: -m64 -O0 -Wall -Wextra -MMD -std=c++11
With linking I have a problem. My command line for the linker:
LIBS = -static -L$(BOOST_LIBS) -l:..boostlibs \
-L$(OPENSSL_LIBS) -l:libssl.a -l:libcrypto.a \
-Wl,-Bdynamic -lc -ldl -lpthread \
-Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2
g++ *.o $(LIBS) -o executablefile
(*.o means list of all object files needed for the app)
This command works fine, app can be launched. But in this app blocks try{} catch(...){} do not work at all. If any exception is thrown - my app terminated.
I made simple app and used only shared libs to build it. I.e. I removed -Wl,-Bdynamic from the linker options. All works fine, exceptions catched.
But my app requires shared libs and I do not know what to do with that.
How to fix catching of exceptions?
P.S.
Arguments -Wl,-Bdynamic -lc -ldl -lpthread needed because without them I get error from the linker:
/home/.../openssl/openssl-1.0.2h-x64-build/lib/libcrypto.a(dso_dlfcn.o):
In function dlfcn_globallookup': dso_dlfcn.c:(.text+0x11): warning:
Using 'dlopen' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
/home/.../xxx.o: In
function
boost::asio::detail::resolver_service::resolve(std::shared_ptr&,
boost::asio::ip::basic_resolver_query const&,
boost::system::error_code&)':
xxx.cpp:(.text._ZN5boost4asio6detail16resolver_serviceINS0_2ip3tcpEE7resolveERSt10shared_ptrIvERKNS3_20basic_resolver_queryIS4_EERNS_6system10error_codeE[_ZN5boost4asio6detail16resolver_serviceINS0_2ip3tcpEE7resolveERSt10shared_ptrIvERKNS3_20basic_resolver_queryIS4_EERNS_6system10error_codeE]+0xd7):
warning: Using 'getaddrinfo' in statically linked applications
requires at runtime the shared libraries from the glibc version used
for linking
This error perfectly described here and seems that I have to use shared libraries.
Argument -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 needed because g++ not able to locate path to the shared lib ld. And if I try to launch compiled app I got error: No such file or directory.
P.S. 2
I use Ubuntu 16.04.2 and gcc 5.4.0
UPD
Just to be clear.
If I add code below to the start of the main function - my app terminated.
try
{
throw std::exception();
}
catch(...)
{
std::cerr << "hello from the catch.";
}
I'm trying to use X86_64-w64-mingw32-g++ (packaged in Archlinux's MingW package) to cross compile some C++ code into an Windows executable, however I'm having trouble getting past some issues.
I'm calling
x86_64-w64-mingw32-g++ -o build_win/asm build_win/asm.o build_win/asm_lib.o build_win/socket_boost.o -I../extra/etc -fopenmp -lrt -std=c++11 -g -lboost_system -lboost_serialization
from a makefile, but I get thrown the errors:
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lrt
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_system
/usr/lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lboost_serialization
This works fine with native g++, so exactly do I have to change for mingw to compile?
EDIT: I have mingw-w64-boost package installed, which includes boost libraries pre-compiled and ready to be linked. However, it seems the naming convention is a bit different, and -lboost_system for example becomes -llibboost_system-mt (not exactly sure what the -mt suffix entails).
Problem is I can't find the mingw counterpart for -lrt. I've tried with both -lrtm and -lrtutils but in both cases I get:
[...]
undefined reference to `__imp_getsockopt'
Are you sure that -lboost_system and other libraries are present in the same directory as makefile ?
If not then please include -L flag which indicates the location of your library.
For example:
-L /path_openmp -fopenmp -L /path_boost_system/ -lboost_system -L /path_serialization -lboost_serialization
Moreover, you need not include -I and -g flag when creating an executable from .o files. These are needed when you create .o from .cpp files.
There is no rt library on Windows.
You are missing -lws2_32.
$ x86_64-w64-mingw32-nm -A /usr/x86_64-w64-mingw32/lib/*.a 2>/dev/null | grep getsockopt | grep " T "
I am trying to build an image processing program written in C++ that depends on the following libraries using MinGW + MSYS (with GCC4.8.1) that I downloaded from www.mingw.org/ on a Windows 8 64bit computer
LibJPEG
BLAS and LAPACK
Armadillo
OpenMP
I have successfully compiled all the source code files (with -fopenmp flag of course), then I linked with the following statement:
g++ -o ./build/rspfitter {a list of .o files}
-L{paths to libraries} -ljpeg -lopenblas -lgomp -lpthread
The executable was correctly produced. However, it asks for the following dlls:
libgomp-1.dll
libpthread-2.dll
pthreadGC2.dll
I think it might a better idea to link libgomp and libpthread statically, so that I can minimize the number of dlls I need to deploy my program with (the above three dlls are not the only ones the program depends on). So I tried to link only libgomp and libpthread statically with the following command:
g++ -o ./build/rspfitter {a list of .o files}
-L{paths to libraries} -ljpeg -lopenblas -Wl,-static -lgomp -lpthread
But this time it fails with the following error message:
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0xbfe):
undefined reference to `_imp__pthread_attr_init'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0xc13):
undefined reference to `_imp__pthread_attr_setdetachstate'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o):(.text.startup+0x3c):
undefined reference to `_imp__pthread_attr_setstacksize'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
d:/mingw/bin/../lib/gcc/mingw32/4.8.1\libgomp.a(env.o): bad reloc
address 0x0 in section `.ctors'
d:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
final link failed: Invalid operation
Then I tried to execute the exact same compiling and linking commands using the MinGW + GCC 4.8.1 environment that was installed together with CodeLite. It fails again with different error messages：
./tmp/hshfitcmdline.o:hshfitcmdline.cpp:(.text.unlikely+0x105):
undefined reference to `_Unwind_Resume'
./tmp/hshfitcmdline.o:hshfitcmdline.cpp:(.text$_ZN9NormalMapD1Ev[__ZN9NormalMapD1Ev]+0xb4):
undefined reference to `_Unwind_Resume'
d:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
./tmp/hshfitcmdline.o: bad reloc address 0xb4 in section
`.text$_ZN9NormalMapD1Ev[__ZN9NormalMapD1Ev]'
d:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
final link failed: Invalid operation collect2.exe: error: ld returned
1 exit status make: *** [build/rspfitter] Error 1
I confirmed that the file "libgomp.a"/"libgomp.dll.a" was present on the [MinGW dir]/lib/gcc/mingw32/4.8.1/ for both installations of MinGW. However, they are of different sizes! In installation downloaded from MinGW.org, 'libgomp.a' is of 86kb, and "libgomp.dll.a" is of 87kb; In the CodeLite installation, however, the sizes are 74kB and 148Kb respectively.
Now I am wondering:
What could be the cause of the error messages given by the two MinGW systems? Could it be that the statically libraries that I downloaded from MinGW are corrputed? But dynamically linking was perfectly fine on both systems.
How on earth can I correctly link libgomp statically?
Thanks
To link libgomp statically you can do
ln -s `g++ --print-file-name=libgomp.a` && \
g++ foo.o -static-libgcc -static-libstdc++ -L. -o foo -fopenmp -ljpeg -lopenblas
However your executable will still depend on a pthread dll. The reason you are getting the error is that libc is still linking dynamically. To fix this you have to link libc statically as well
ln -s `g++ --print-file-name=libpthread.a` && \
ln -s `g++ --print-file-name=libc.a` && \
g++ foo.o -static-libgcc -static-libstdc++ -L. -o foo -fopenmp -ljpeg -lopenblas
However, if openblas or jpeg libraries depend on libc then there will likely still be undefined references.