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

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.