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
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 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?
I need to use the TCC compiler to link object files generated by GCC. However, GCC in MinGW outputs object files in COFF format, and TCC only supports the ELF format. How can I make GCC generate ELF object files?
$ cat test.c
int main(void)
{
return 0;
}
$ gcc -c test.c
$ file test.o
test.o: MS Windows COFF Intel 80386 object file
$ tcc -c test.c
$ file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
However, GCC in MinGW outputs object files in COFF format
GCC can be configured to generate various outputs (including ELF) regardless of which host it runs on.
That is, a GCC running on Linux could be configured to generate COFF, and a GCC running on Windows could be configured to generate ELF32 or ELF64, for various processors (e.g. x86, or SPARC, or MIPS).
A compiler that runs on one kind of host, but generates code for a different kind, is called a cross-compiler.
TCC only supports the ELF format
This is not a meaningful statement: it could mean that you want GCC to generate ELF32 for i686 Linux, or ELF64 for SPARC Solaris, or any number of other processor/os/bit combinations.
You should figure out what target processor and operating system you want to run your final executable on, and then build (non-trivial) or download appropriate cross-compiler from Windows to that target.
file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
Ok, you want Windows to Linux/i386/ELF32 cross-compiler.
strip might help. strip accepts various object file formats for input and output type (the bfdname). strip --info for the supported formats.
strip -o outputname -O elf32-i386 objfile Doing so on a 64 bit executable, converted to 32bit control headers will lead to nothing but crash, so pick your output form carefully. Make sure you aren't changing assumed bitwidths / endians along with headers.
Not running MinGW, so, not tested, may not work for your needs, or worse, may jump and catch fire.
You want your compiler (MinGW) to generate binaries that are not of the type usable for your host system (Windows). This is called cross-compiling, and it is a somewhat involved subject -- because to create complete executables you will also need the various libraries: standard libraries, target OS libraries, third-party libraries... so it is not merely the subject of "how do I get the compiler to create ELF", but also "how do I get the whole supporting cast of ELF libs so I can link against them?".
OSDev has quite extensive documentation on the subject of setting up a cross-compiler; however, since you did not tell us what exactly your problem is, it is difficult to advise you further.
If what you want is generating Linux binaries, my advise would be to not bother with cross-compilation (which is a tricky subject -- and much better supported the other way around, i.e. targeting Windows from Linux), but rather install a Linux distribution in parallel to your Windows, and work natively with that.
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.