Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Cross-compiled Qt5.9.2 for RPi B+ leads to non executable binaries
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:
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?
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!
One thing that comes to mind, is the sysroot you are running on the RPi also built for hard-float ?
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
/mnt/raspi-pi-rootfsI mounted the Raspbian image file.
Do you see any evidence of mistakes here?
Looks good from here...
What do you get if you call
fileon one of the sysroot executable ?
$ 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
@Mark81 Try to run in a debugger to see where exactly it happens (is it your executable or one of the shared libs?).
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...
So basically a big cleanup and rebuild ?
@SGaist Exacly. Sorry for the delay but I didn't receive the notification.
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 :)
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 :-)
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.