I am trying to build a 64-bit MIPS big endian cross-compiler toolchain. I have been using the following guide (substituting aarch64 for mips64):
https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
I have used the following versions of each library mentioned in the guide:
binutils-2.31.tar.gz
gcc-7.3.0.tar.gz
linux-4.18.tar.gz
gmp-6.1.2.tar.xz
mpc-1.1.0.tar.gz
mpfr-4.0.1.tar.gz
isl-0.18.tar.bz2
cloog-0.18.1.tar.gz
I have successfully built the toolchain, yet it is producing the following binary:
ELF 32-bit MSB executable, MIPS, N32 MIPS64 version 1 (SYSV), dynamically linked, interpreter /lib32/ld-uClibc.so.0, with debug_info, not stripped
However, what I need is the following:
ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, for GNU/Linux 2.6.12, stripped
Does anyone know what step I am doing incorrectly that is preventing the appropriate binary being built?
Related
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 know go doesn't have multi architecture support in their binary. I am cross compiling a go dbus application and the cross compiled binary is still running on my host computer. I am running debian testing. Can this be a coming up feature or so?
$ go version
go version go1.11.5 linux/amd64
$:golang-godbus$ go build
$:golang-godbus$ file golang-godbus
golang-godbus: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=rtpT-vZ73aaq-OWCmm29/BqcyUmwm1ybWYgaZEdN7/Ll0SYgA2TzwyWDpTcfmI/fZ-z5lzvDaDWOFC4XHw8, not stripped
$:golang-godbus$ GOOS=linux GOARCH=arm GOARM=7 go build
$:golang-godbus$ file golang-godbus
golang-godbus: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=GgidUi9KoU1Ku-VzGDlJ/Lb9Rrl0prlg6BfmlJhvv/Lt1JZ03bbrg1XFqGdA1Q/VNKiL2-y3UnN_7F4P8IP, not stripped
$:golang-godbus$ ./golang-godbus
Currently owned names on the session bus:
org.freedesktop.DBus
:1.15319
:1.7
org.freedesktop.login1
org.freedesktop.timesync1
:1.10601
:1.10603
org.freedesktop.systemd1
:1.11095
:1.10605
org.freedesktop.PolicyKit1
org.freedesktop.Avahi
org.freedesktop.ModemManager1
org.freedesktop.NetworkManager
:1.11
:1.241
org.freedesktop.UDisks2
org.freedesktop.network1
:1.7704
:1.233
fi.epitest.hostap.WPASupplicant
:1.4
fi.w1.wpa_supplicant1
:1.23524
:1.19
:1.6
I'm trying to cross-compile zaptel driver for Arm
I'm following this project http://svn.astfin.org/software/baps/trunk to build zaptel driver for blackfin arch. After building uClinux, oslec and patching zaptel.patch to build extra modules wcfxs, sport_interface, bfsi instead of original one, this command does the magic
make -C /home/working/BAPS/uClinux-dist/linux-2.6.x/ SUBDIRS=/home/working/BAPS/zaptel-1.4.3/ modules V=1 ARCH=blackfin CROSS_COMPILE=bfin-uclinux- EXTRA_CFLAGS="-DCONFIG_4FX_SPI_INTERFACE"
Build process run successfully, bfsi.ko, sport_interface.ko, wcfxs.ko, zaptel.ko generated and useful for my astfin board (well, also the oslec.ko in the previous process).
bfsi.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
sport_interface.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
wcfxs.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
zaptel.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
So then I want to do the same thing with my arm board (particularly my Beaglebone Black).
Firstly, I completely built BBB Kernel, and then the oslec. I know oslec is also a kernel module but I easily built it.
make -C [my bbb kernel] ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRA_CFLAGS="-I/home/working/AAPS/oslec/kernel -I/home/working/AAPS/oslec/spandsp-0.0.3/src/spandsp" SUBDIRS=/home/working/AAPS/oslec/kernel modules
I have the oslec.ko and it looks ok.
kernel/oslec.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
But I got stuck in the final step - building zaptel
Here's my make command
make -C /home/working/AAPS/dl/buildroot-bbb/output/build/linux-3.8.13/\
SUBDIRS=/home/working/AAPS/zaptel-1.4.3/ modules V=1 ARCH=arm\
CROSS_COMPILE=arm-linux-gnueabihf- KBUILD_NOPEDANTIC=1\
EXTRA_CFLAGS="-DCONFIG_4FX_SPORT_INTERFACE -I/home/working/AAPS/zaptel-1.4.3/staging/usr/include "
come with error:
include/linux/wait.h:159:47: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
#define wake_up_interruptible(x) __wake_up(x, TASK_INTERRUPTIBLE, 1, NULL)
I figured out that the constant TASK_INTERRUPTIBLE was defined in $(my_bbb_kernel)/include/linux/sched.h and $(blackfin_uclinux_kernel)/linux-2.6.x/include/linux/sched.h, but one works (uclinux for blackfin) and one does not (my bbb kernel). I dont know how can they included cause i'm not so familiar with linux kernel module development.
So if anyone have any idea in this case, please give me some instructions or explains.
Best Regards
Loi Dang
I am trying to generate 64 bit native code for Android 64 bit platform , but i am not able to generate it , even after successful compilation the generated native code is showing 32 bit ( "ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped").
I have used "arm-linux-androideabi-" toolchain from NDK r9 x86_64 .
I will grateful if someone explain what should i do exactly to generate native code for 64 bit Android Or it is not possible to generate 64 bit code.
Thanks,
It will not be easy to compile for 64-bit arm with NDK r9. NDK r10 has prebuilt toolchains for 64-bit ARM. If you download NDK r10 and look in the /toolchains directory, you will see:
aarch64-linux-android-4.9
aarch64-linux-android-clang3.4
aarch64-linux-android-clang3.5
Those are the gcc and clang 3.4 and 3.5, respectively, toolchains for building 64-bit ARM.
You can download the new toolchains from the usual distribution point, which is here:
https://developer.android.com/tools/sdk/ndk/index.html
You need to use an arm64 toolchain from r10. The arm toolchain is strictly 32 bit arm.
I am cross compiling the open source library oRTP for MIPS processor (little-endian arch). My development system is i386 linux. I run the configure script as
./configure --host=mips-linux
The configure script uses the mips-linux-gnu-gcc compiler and builds the library. However when I try to link the library with an executable, I get undefined symbols saying that the ortp lib is built for big-endian and that the target is little-endian.
Running file command on an existing executable on the target shows
ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically
linked (uses shared libs), for GNU/Linux 2.6.12, with unknown
capability 0xf41 = 0x756e6700, with unknown capability 0x70100 =
0x1040000, not stripped
And running file on the ortp object file shows
ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), with
unknown capability 0x41000000 = 0xf676e75, with unknown capability
0x10000 = 0x70401, not stripped
Even though both are built for MIPS, the existing executable is LSB where as the ortp compiled object file is MSB.
How do I compile for MIPS and LSB so that linking goes fine?
Well, I feel terrible about myself. I explicitly gave the CC compiler as mipsel-linux-gcc and the issue was resolved.
CC=/path/to/mipsel-linux-gcc ./configure --host=mips-linux
So the way to go is to use mipsel-linux-gcc compiler in case you are compiling for little endian mips processor and use mips-linux-gcc only compiler for big-endian mips processtors.