I am trying to cross compile the ipsectools(ipsec-tools-0.8.2) downloaded from opensource for the mips architecture.
I downloaded ipsectools from : https://sourceforge.net/projects/ipsec-tools/
and applied a patch as mentioned in : https://dev.openwrt.org/browser/packages/net/ipsec-tools/patches/006-linux-3.7-compat.patch?rev=35312
Susequently after extracting and applying patch, i used the following commands,
./bootstrap
autoconf
./configure --enable-security-context=no CXX=${CROSS_COMPILE}g++ CC=${CROSS_COMPILE}gcc AS=${CROSS_COMPILE}as AR=${CROSS_COMPILE}ar LD=${CROSS_COMPILE}ld NM=${CROSS_COMPILE}nm OBJCOPY=${CROSS_COMPILE}objcopy OBJDUMP=${CROSS_COMPILE}objdump RANLIB=${CROSS_COMPILE}ranlib READELF=${CROSS_COMPILE}readelf STRIP=${CROSS_COMPILE}strip --host=mips-wrs-linux-gnu --build=i586-wrs-linux-gnu
Now if i crosscompile for mips architecture it compiles successfully for mips. But the racoon binary file created shows following
[samb#bhlinv09 racoon]$ file racoon
racoon: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with unknown capability 0x410000000f676e75 = 0x1000000070403, not stripped
Can anyone tell me what is this "unknown capability error"?
Related
I'm working with a Target board which use micro controller MCIMX6DP6AVT8AA - i.MX 6 series 32-bit MPU, Dual ARM Cortex-A9 core, 850MHz, FCBGA 624
(refer http://www.nxp.com/webapp/search.partparamdetail.framework?PART_NUMBER=MCIMX6DP6AVT8AA). My board run Linux kernel 3.1.1
I use cross-compile toolchain arm-poky-linux-gnueabi, run on host Ubuntu14.04 to build a Application for Target board. After built successful, i checked the output file as below
~$ file MyApp
MyApp: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1,
BuildID[sha1]=a800b4033343517d3368a3f3ca0c87eb98f6c1ba, not stripped
But when i run it on Target board, there was error
~$ ./MyApp
-sh: ./MyApp: No such file or directory
I don't know what i did wrong ?
The message is very likely coming from the dynamic linker. Look at the output of:
ldd MyApp
It will tell you all the library dependencies and where they are found on the system. Install those which hadn't been found.
I am trying to cross-compile a binary to use on an old Linux distribution (kernel 2.4.25, i586 architecture).
Steps I took
I have downloaded the landley i586 cross-compiler (http://landley.net/aboriginal/downloads/binaries/)
I downloaded the net-utils source: https://ftp.gnu.org/gnu/inetutils/ version 1.9.4
I included the cross-compiler in my path: export PATH=/root/Documents/cross-compiler-i586/bin/:$PATH
I then built the telnet binary as follows: LDFLAGS=”-static" ./configure --host=i586 --build=x86_64 --target=i586 --disable-ifconfig --with-ncurses-include-dir=/root/Documents/tnbuild --disable-hostname --disable-logger --disable-rcp --disable-rexec --disable-rlogin --disable-rsh --disable-tftp --disable-traceroute --disable-inetd --disable-rexecd --disable-syslogd --disable-tftpd
This successfully compiled, and checking (after stripping) the binary with the file command gives: telnet: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
I compared this with a binary which is already on the old Linux system, and the output is exactly the same: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter lib/ld-linux.so.2, for GNU/Linux 2.4.0, stripped
The problem I am facing
The telnet binary that I compiled is not working on the old Linux system. The error that is thrown is simply 'Segmentation Fault'. Googling this error learns that it is likely due to differences in architecture (i586?), but I have no clue anymore how to fix it, as the 'file' command outputs exactly the same for a working binary as well as for the failing binary.
I then stumbled across this topic: GCC Cross compile to a i586 architecture (Vortex86DX) , but as it is not pursued, I am not sure if I should indeed compile all toolchains for i586 and how exactly I would need to do that.
Is there a specific reason you want to cross-compile this rather than just compiling for generic 32-bit i386? You may need to disable some compiler optimizations if they are not supported by the CPU, but you probably don't need to create a staticly-linked binary.
These instructions for compiling 32-bit (-m 32) seem sufficient to create the telnet binary.
They boil down to:
apt-get install gcc-multilib;
./configure CFLAGS='-m32' -disable-ifconfig \
--with-ncurses-include-dir=/root/Documents/tnbuild \
--disable-hostname --disable-logger --disable-rcp \
--disable-rexec --disable-rlogin --disable-rsh \
--disable-tftp --disable-traceroute --disable-inetd \
--disable-rexecd --disable-syslogd --disable-tftpd
make
I'm planning to build DAHDI for Beagleboneblack
Firstly, I built the kernel for BBB completely by following this tutorial
http://elinux.org/Building_BBB_Kernel,
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- beaglebone_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage dtbs
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- uImage-dtb.am335x-boneblack modules
I used linaro toolchain for armhf (CROSS_COMPILE=arm-linux-gnueabihf-) instead of the instructed one.
And then I start building the DAHDI :
cd dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2
cd linux/ # I build the dahdi only, not their tools
make KSRC=PATH_TO_MY_ABOVE_KERNEL
Unfortunately, process ends with the following error when compiling the dahdi-base.c :
/home/working/dl/dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2/linux/drivers/dahdi/dahdi-base.c:1: error: code model kernel not supported in the 32 bit mode
/home/working/dl/dahdi-linux-complete-2.10.1-rc2+2.10.1-rc2/linux/drivers/dahdi/dahdi-base.c:1: sorry, unimplemented: 64-bit mode not compiled in
I have no idea why, because my linaro toolchain is 32-bit
/home/working/dl/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux/bin/arm-linux-gnueabihf-gcc-4.7.3:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
and my gnu gcc toolchain is 32-bit as well.
/usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
If anybody gets an idea, your help would be appreciated.
Best Regard.
Loi Dang Thanh
I'm making this answer to make sure everyone else who get into my issue can search and solve the problem in the future.
Just add 2 more ARGS to the make command when building DAHDI, and the problem solved pretty well.
make KSRC=PATH_TO_MY_ABOVE_KERNEL ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
A big thanks to Miline who get me out of the stuck.
Best Regards
Loi Dang.
I can not find any built versions of the binutils that could be pushed to an Android device an then be executed from there. The Android NDK toolchain provides them but in the wrong format.
Devices need them in ELF 32bit executable for ARM , but the toolchain only provides :
compiledtoolchain/bin$ file arm-linux-androideabi-objdump
arm-linux-androideabi-objdump: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
Does anyone know if and where to find objdump in a format so that it can be executed directly on an ARM android device ?
I haven't tried it on an Android device, but you might want to look at the pre-built binaries of my ELLCC cross compiler project: ftp://ellcc.org/pub (http://ellcc.org). Each tarball contains binaries for the clang/LLVM based C/C++ compiler, pre-built libraries, gdb, and the GNU binutils. All of the executables are statically linked so they don't rely on any shared libraries being available on the target system.
I have a development kit ( Altera Cyclon V, Cortex A9) and I'm trying to run a simple app on it.
I'm using cygwin for cross compiling my code for ARM Linux (using soureforge toolchain for Linux ).
Steps :
build within cygwin : arm-linux-gcc dd.c -s -mcpu=cortex-a9 -s -o ddb
copy ddb to target and chmod a+x
running it gives me "./ddb: No such file or directory" .
probably a mismatch between lib\tools but I'm new to Linux ( coming from QNX ).
Target is running :
root#socfpga:~/altera# cat /proc/version
Linux version 3.9.0 (jdasilva#sj-interactive3) (gcc version 4.7.3 20121106 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.1
1-20121123 - Linaro GCC 2012.11) ) #1 SMP Fri Sep 27 22:55:43 PDT 2013
File data of my app :
ddb: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared
libs), for GNU/Linux 2.6.33, stripped
File data of a sample hello_world that runs on target :
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (use
s shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=0x2e8fbebd0bdab5897c0c65fb6b
563f3c34a16eb1, stripped
I can see that different DLL are being used ( 2.6.31 vs 2.6.33 ).
How can I solve this?
I've had that problem before when I tried to copy ARM binaries to an ARM android device.
You solved it, but either way, this is what I found out. The problem was the shared libraries. It is trying to load a library that doesn't exist on the target. The "file not found" error is very misleading.
Related question and answers:
"No such file or directory" but it exists
could be 64<>32bit problem.
See this