I download the w_scan project(a small command line utility used to perform frequency scans for DVB and ATSC transmissions.) from http://wirbel.htpc-forum.de/w_scan/index_en.html. I also install gcc-arm-linux-gnueabi on my Ubuntu x86_64. I use the ./configure --host=arm-linux CC=arm-linux-gnueabi-gcc command to cross-compile, and it generates a binary file. However, I copy that file to my target board and execute that file, it shows sh: ./w_scan: No such file or directory.
I use the file command to see information of that binary file, it shows ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0x9a584b4720fadf5eb5b77034ac85092daeb728c9, not stripped.
I found that error message stands the configuration of cross-compile doesn't correct.(reference http://ubuntuforums.org/showthread.php?t=1141792). How can I fix my configuration and correct cross-compile that project, THANKS!
./configure --host=arm-linux CC=arm-linux-gnueabi-gcc
make CFLAGS=-static
copy that binary file to my target board, it can execute normally and successfully.
And the file w_scan will shows
ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.31, BuildID[sha1]=0x67b7e9f93015607f891c0b77493d9e47059ef6a1, not stripped.
Related
I am trying to cross compile a small rust application for the RPI. I am cross compiling because compiling directly on the PI takes way too long and it hits 75C.
I followed various instructions, but what I ended up doing is this:
Install "armv7-unknown-linux-gnueabihf" target with rustup
Download rpi tools from here: https://github.com/raspberrypi/tools
Add the "tools/arm-bcm2708/arm-linux-gnueabihf/bin/" folder to PATH
Add ".cargo/config" file with:
[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"
run "cargo build --target armv7-unknown-linux-gnueabihf --release"
scp the file to the RPI
chmod +x the_file
do "./the_file"
I get bash: ./the_file: No such file or directory
Yes, I am indeed in the right directory.
So this is the output from "file":
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
with debug_info, not stripped
I'm not experienced enough with this sort of stuff to determine if the binary that I produced is suitable to be run on an RPI3 B.
Did I produce the correct "type" of binary?
P.S. I am running DietPi distro on the PI. It is based on debian if that's of any relevance.
So I solved this by cheating. I found https://github.com/rust-embedded/cross which took about 30 seconds to get going and now I can cross compile to pretty much anything. I highly recommend it!
The error message "No such file or directory" is not about the your executable but about the dynamic libraries linked to it which are missing from the target system.
To find out which libraries your executable needs you have to run the following command.
ldd /usr/bin/lsmem
This will output something like this
linux-vdso.so.1 (0x00007fffc87f1000)
libsmartcols.so.1 => /lib/x86_64-linux-gnu/libsmartcols.so.1 (0x00007fe82fe71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe82fc7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe82fedd000)
Now you have to check that all this libraries are available on your system. rust-cross probably uses the correct linker for your target so that is probably the reason this works with it. To modify the linker see https://stackoverflow.com/a/57817848/5809980
I am trying to do profiling of the code written in C++ with the target Architecture RISC-V. The code has been cross-compiled using RISC-V GNU Toolchain. My executable is unit_tests "ELF 64-bit LSB executable, UCB RISC-V, version 1 (GNU/Linux), dynamically linked,nterpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, with debug_info, not stripped" this information is retrieved using the file command.
What I am trying to do is the profiling of this using gprof. But to do the gprof gmon.out needs to be generated, to generate gmon.out the executable should be run first. I cannot run the binary elf of other architecture in some different architecture. I need a suggestion for this on which emulator or simulator does this for me or I can run on?
I have tried installing qemu using the follwing link:
https://www.google.com/url?q=https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html&sa=D&source=hangouts&ust=1597422417473000&usg=AFQjCNERr6pHYmj0SU6an3WkBRGQI52aTw
but not able to successfully install it.
Also have tried with spike but got "bad synccall" error. Any leads how can I resolve this issue.
I solved this issue using qemu in user mode. Following the instructions in the below link:
Manual-qemu-user
Where I could run the binary elf generated for target RISC-V, which I could run on x86 Linux machine.
I just created a gcc11 crosscompiler with crosstool-ng for "arm-unknown-eabi" to compile my kernel (android for msm8974 chipset), but at some point of the linking, the LD gives this error about EABI versions, but the target file doesn't even exists.
These are the components of the crosstool toolchain:
binutils-2.34.tar.xz
gcc-git-46a58c77.tar.bz2
gettext-0.20.1.tar.xz
gmp-6.2.0.tar.xz
isl-0.22.tar.xz
libiconv-1.16.tar.gz
mpc-1.1.0.tar.gz
mpfr-4.0.2.tar.xz
ncurses-6.2.tar.gz
newlib-3.3.0.tar.gz
The full command that gives the error is this:
/root/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld -EL -r -o drivers/gpu/built-in.o drivers/gpu/drm/built-in.o drivers/gpu/ion/built-in.o
/root/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: error: source object drivers/gpu/ion/built-in.o has EABI version 5, but target drivers/gpu/built-in.o has EABI version 0
/root/x-tools/arm-unknown-eabi/bin/arm-unknown-eabi-ld: failed to merge target specific data of file drivers/gpu/ion/built-in.o
Looking at these files:
drivers/gpu/built-in.o: cannot open `drivers/gpu/built-in.o' (No such file or directory)
drivers/gpu/drm/built-in.o: ELF 32-bit LSB relocatable, ARM, version 1 (ARM), not stripped
drivers/gpu/ion/built-in.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
The real target (drivers/gpu/built-in.o) doesn't even exist. The DRM one (which doesnt show as EABI5) is there although very small (320 bytes, I think it's created by AR?).
With another toolchains everything goes nicely with this exact same kernel code, Makefile, etc. I was using musl gcc 10 before.
I try to debug this file
and got error
not in executable format: file format not recognized
the 'file' command output
canary: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked,
interpreter /lib/ld-linux.so.2, BuildID[sha1]=377711637c79e57303ff92f946500aed1b42c73a, for
GNU/Linux 3.2.0, not stripped`
the other answer seem not working for me.
The ELF binary executable format is standard in Linux and other Unixes. It is not compatible with macOS, which uses the Mach-O binary format.
Whatever you are attempting to analyze must be recompiled into a Mach-O binary.
macOS Catalina is not supporting 32bit Applications anymore.
I guess this is true for executables too.
See 32-Bit Apps will no longer work on macOS Catalina: Here’s what to do
I receive this error when linking -lboost_thread into my executable on google Native Client (pepper_19):
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/x86_64-nacl/usr/lib/libboost_thread.a: could not read symbols: Archive has no index; run ranlib to add one
I compiled boost according to the instructions at naclports here: http://code.google.com/p/naclports/wiki/InstallingSDL (except using the boost library directory instead of SDL... I also used this same process to correctly compile NaCl zlib library)
cd naclports/src/libraries/boost_1_47_0
export NACL_PACKAGES_BITSIZE=32; ./nacl-boost_1_47_0.sh
export NACL_PACKAGES_BITSIZE=64; ./nacl-boost_1_47_0.sh
this generates the libboost_thread.a file and puts it them in the /usr/lib directories of my NACL installation. I thought maybe somehow I mistakenly built a wrong type of library for linking with NaCl. Is there a way to check this and/or fix it?
I tried:
cd naclports/src/out/repository-x86_64/boost_1_47_0/bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi
nm libboost_thread.a
and this yielded:
libboost_thread.a(thread.o):
0000000000052d08 s EH_frame0
000000000004f50c s GCC_except_table100
000000000004f534 s GCC_except_table101
000000000004f574 s GCC_except_table102
000000000004f5c0 s GCC_except_table103
000000000004f600 s GCC_except_table104
000000000004f64c s GCC_except_table105
000000000004f68c s GCC_except_table106
000000000004f6d8 s GCC_except_table107
.
.
.
.
etc, etc..
However then I ran:
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm libboost_thread.a
and got:
__.SYMDEF SORTED: File format not recognized
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm: thread.o: File format not recognized
nacl_sdk/pepper_19/toolchain/mac_x86_glibc/bin/x86_64-nacl-nm: once.o: File format not recognized
And finally. I ran:
file pthread/thread.o
pthread/thread.o: Mach-O 64-bit object x86_64
however the same command on a zlib object file results in:
ELF 64-bit LSB relocatable, x86-64, version 1, not stripped
I would appreciate advice on building a correctly cross-compiled NaCl libboost_thread.a
Thank you.
Some libraries in NaCl ports can only be built on linux. So you have to either find why boost decides to use system ar instead of x86_64-nacl-ar or install VM with linux where they are the same.