Error running cross-compiled code with pthread - linux

I'm uing ARM_EABI cross-compiler to compile a code that makes use of pthreads to run at an ARM Cortex A9 simulation.
While I'm able to compile it with no problems (just as I've did with others non-pthread applications, which ran fine in the simulation), I'm having an error message when trying to run my pthread application at the simulated ARM (which is running Linux as OS). It's the following:
./pttest.exe: /lib/libpthread.so.0: no version information available (required by ./pttest.exe)
I did my research and found out that's because it's a dynamic lib, and I'm compiling the application with a higher version than the one available on my simulator.
My question is: how to find force my cross-compiler to compile the application with the same pthread lib version of my simulator? Is there anywhere I can download different versions of pthreads? And how to set it?
Sorry, I'm quite a newbie in that area.

Try compiling your application statically, e.g.
gcc -static -o myapplication myapplication.c

Related

Build static executable on RHEL 7?

I have a C++ project that I'm currently building using dynamic linking to various system libraries. It's on a RHEL 7 system. I've been using devtoolset-9 to get a more modern version of g++ (the system one is 4.8.5, I think). It all works fine, but I'd like to now build a static executable that I will be able to run on a non-RHEL linux system. I've tried specifying -static-libstdc++, but it appears to still be dynamically linked, looking at the ldd output. I've read that devtoolset compilers use some link-time trickery to link in both the system libstdc++ dynamically and any new C++ functionality statically. Is this true? It doesn't work for me; if I copy the executable over to the non-RHEL system and try to run it, I get a bunch of things like this (from memory, so hopefully correct):
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
Is there any way to build a fully static executable using g++ from devtoolset-9? Thank you.

What is the toolchain to be used to compile Berkeley bootloader (bbl)?

I have to run riscv-tests and SPEC2006 on riscv-linux (booted) on FPGA. I would like to know what is the compilation toolchain to be used for this flow.
I understand that riscv-linux has to be compiled with riscv64-linux-gcc. However, I'm unclear that about riscv-tests. Can riscv-elf-gcc be used to compile riscv-tests and run on riscv-linux? I read some of the posted mentioned in stackoverflow about SPEC2006 and bbl (both compiled with riscv-linux-gcc). I want to run riscv-tests also. Should they also be compiled with (riscv-linux-gcc) ?
Thanks!
To compile bbl or baremetal applications like riscv-tests you should you riscv64-unknown-elf- or riscv32-unknown-elf- (with Newlib) .
Because riscv64-linux contains more libraries that make compilation process complicated.We mainly use riscv64-linux to compile application that run on riscv-linux.

Can gcc produce binary for Arm without cross compilation

Can we configure gcc running on intel x64 architecture to produce binary for ARM chip by just passing some flags to gcc and not using a cross compiler.
Short: Nope
Compiler:
gcc is not a native crosscompiler, the target architecture has to be specified at the time you compile gcc. (Some exceptions apply, as for example x86 and x86_64 can be supported at the same time)
clang would be a native crosscompiler, and you can generate code for arm by passing -target=arm-linux-gnu, but you still cant produce binaries, as you need a linker and a C-library too. Means you can run clang -target=arm-linux-gnu -c <your file> and compile C/C++ Code (will likely need to point it to your C/C++ include paths) - but you cant build binaries.
Rest of the toolchain:
You need a fitting linker and toolchain too, both are specific to the architecture and OS you want to run at.
Possible solutions:
Get a fitting toolchain, or compile your own. For arm linux you have for ex. CrossToolchains if you are on debian, for barebones you can get a crosscompiler from codesourcery.
Since you were very vague, its not possible to give you a clearer answer

Compiling Basic C-Language CUDA code in Linux (Ubuntu)

I've spent a lot of time setting up the CUDA toolchain on a machine running Ubuntu Linux (11.04). The rig has two NVIDIA Tesla GPUs, and I'm able to compile and run test programs from the NVIDIA GPU Computing SDK such as deviceQuery, deviceQueryDrv, and bandwidthTest.
My problems arise when I try to compile basic sample programs from books and online sources. I know you're supposed to compile with NVCC, but I get compile errors whenever I use it. Basically any sort of include statement involving CUDA libraries gives a missing file/library error. An example would be:
#include <cutil.h>
Do I need some sort of makefile to direct the compiler to these libraries or are there additional flags I need to set when compiling with NVCC?
I followed these guides:
http://hdfpga.blogspot.com/2011/05/install-cuda-40-on-ubuntu-1104.html http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA_C_Getting_Started_Linux.pdf
To fix the include problems add the cuda include directory to your compilation options (assuming it is /usr/local/cuda/include):
nvcc -I/usr/local/cuda/include -L/usr/local/cuda/lib test.cu -o test
cutil is not part of the CUDA toolkit. It's part of the CUDA SDK. So, assuming you have followed the instructions and you have added the PATH and LIB directories to your environment variables you still need to point to the CUDA SDK includes and libraries directories.
In order to include that lib manually you must pass the paths to the compiler:
nvcc -I/CUDA_SDK_PATH/C/common/inc -L/CUDA_SDK_PATH/C/lib ...
Although I personally prefer not to use the CUDA SDK libraries, you probably will find easier start a project from a CUDA SDK example.

crosscompile glibc for arm

Good day
Currently, I'm working on an embedded device based on arm-linux. I want to build GCC for my target architecture with Glibc. GCC builds successful, but I have trouble with Glibc build.
I use the latest version of Glibc (ftp.gnu.org/gnu/glibc/glibc-2.12.1.tar.gz) and port for them (ftp.gnu.org/gnu/glibc/glibc-ports-2.12.1.tar.gz)
my configuration line:
../../glibc-2.12.1/configure --host=arm-none-linux-gnueabi --prefix=/home/anatoly/Desktop/ARM/build/glibc-build --enable-add-ons --with-binutils=/home/anatoly/Desctop/ARM/toolchain/arm/bin/
configuration script work fine, but i get some compile error:
...
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/libmemusage_pic.a(memusage.os): In function me':
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/lmemusage.c:253: undefined reference to__eabi+read_tp'
...
I also tried using the old version (2.11, 2.10) but have the same error.
Does anybody know the solution for this problem?
Use a precompiled toolchain, like those provided by code sourcery.
If you want to make your own, optimised (premature optimization is the root of all evil), use crosstool-NG, which is a tool dedicated to cross-compilation toolchain building.
If you are not convinced, and want to do everything with your own hands, ask your question on the crosstool-NG mailing list.
Try substituting arm-linux-gnueabi for arm-none-linux-gnueabi. Check that a compiler, loader etc. with the prefix you used for "host" exist on your path.

Resources