Cross-compiled Qt5.9.2 for RPi B+ leads to non executable binaries

Mark81

I cross-compiled Qt5.9.2 for Raspberry Pi B+ 1.2 with this configure command:

./configure -release -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=~/opt/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- -sysroot ~/opt/sysroot -opensource -confirm-license -make libs -prefix /usr/local/qt5pi -extprefix ~/opt/qt5pi -hostprefix ~/opt/qt5 -v -nomake examples -nomake tests -reduce-exports -no-pch -no-use-gold-linker

But trying to run a binary on the target leads to the following error:

Illegal instruction

so I checked the type of the executable:

file HelloWorld 
HelloWorld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=7d3286cd6b6667c0bf6ce5812cf7451d26330b68, not stripped

it seems correct to me, but I'm afraid about the makespec I used above. Is linux-rasp-pi-g++ suitable for this model of RPi?
What other reasons might cause that error message?

In another forum a user suggested it might be compiled for ARMv7 instead of ARMv6... how to check this?

Mark81

I found in the mkspec:

MAKE_CFLAGS           += \
                          -marm \
                          -mfpu=vfp \
                          -mtune=arm1176jzf-s \
                          -march=armv6zk \
                          -mabi=aapcs-linux

so it seems the ARM version is not the problem... I'm stuck and out of ideas!

SGaist

Hi,

One thing that comes to mind, is the sysroot you are running on the RPi also built for hard-float ?

Mark81

Hi! Thanks for your answer.
My sysroot is derived from Raspbian Stretch. I mean, the RPi runs Stretch, while on the host I created sysroot in this way:

mkdir sysroot sysroot/usr sysroot/opt
rsync -avz /mnt/rasp-pi-rootfs/lib sysroot
rsync -avz /mnt/rasp-pi-rootfs/usr/include sysroot/usr
rsync -avz /mnt/rasp-pi-rootfs/usr/lib sysroot/usr
rsync -avz /mnt/rasp-pi-rootfs/opt/vc sysroot/opt

wget https://raw.githubusercontent.com/riscv/riscv-poky/master/scripts/sysroot-relativelinks.py
chmod +x sysroot-relativelinks.py
./sysroot-relativelinks.py sysroot

in /mnt/raspi-pi-rootfs I mounted the Raspbian image file.
Do you see any evidence of mistakes here?

SGaist

Looks good from here...

What do you get if you call file on one of the sysroot executable ?

Mark81

Examples:

$ file libnih.so.1.0.0 
libnih.so.1.0.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=53e7a96c7d2cda5386d520e2cca9067d05ebae79, stripped

$ file libident.so.0.22 
libident.so.0.22: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=463ba06c3a7be6e6a27abd8a8fb335d13bcb695d, stripped

$ file bluetoothd 
bluetoothd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=d052a44b1fc4636cd20430e12d66f79424bb0ea2, stripped

jsulm

@Mark81 Try to run in a debugger to see where exactly it happens (is it your executable or one of the shared libs?).

Mark81

Well, this is a situation that I hate.
I wasn't able to find a solution. Hence I restarted from scratch the compilation, using the very same commands (I put them in a script, to avoid any error typing them) and NOW the bins work on the very same RPi...

SGaist

So basically a big cleanup and rebuild ?

Mark81

@SGaist Exacly. Sorry for the delay but I didn't receive the notification.

SGaist

No worries !

Since you have it working now, please mark the thread as solved so other forum users may know a solution has been found :)

Mark81

I'll do, but it won't be very useful for others... rebuild everything without knowing what's happened is like turn off and turn on the computer when it doesn't work :-)

SGaist

I agree, could be anything from old build artefacts to gremlins playing with the processor barrel shifter but at least doing a clean build was a solution.