1

For my project I need to compile Qt 5.9.1 for a generic ARM device. I've set up linaro's toolchain. But Qt configure halts at this:

/usr/bin/arm-linux-gnueabihf-g++ -mfloat-abi=hard --sysroot=/mnt/elvees-rootfs/ -Wl,-O1 -fuse-ld=gold -o verifyspec verifyspec.o
/usr/bin/arm-linux-gnueabihf-ld.gold: error: /lib/libc.so.6: incompatible target /usr/bin/arm-linux-gnueabihf-ld.gold: error: cannot open /lib/ld-linux-armhf.so.3: No such file or directory /usr/bin/arm-linux-gnueabihf-ld.gold: error: /lib/libc_nonshared.a(elf-init.oS): incompatible target ../sysdeps/arm/start.S:124: error: undefined reference to '__libc_start_main' ../sysdeps/arm/start.S:128: error: undefined reference to 'abort' ../sysdeps/arm/start.S:113: error: undefined reference to '__libc_csu_fini' ../sysdeps/arm/start.S:120: error: undefined reference to '__libc_csu_init' collect2: error: ld returned 1 exit status

From the looks of it, arm-linux-gnueabihf-g++ looks for libs in host's /lib/ directory, instead of the sysroot's. Any reason for such a behavior and how to fix it? My best bet is the broken symlinks in the mounted sysroot, but I've manualy changed the "libc.so.6" one, and the output is still the same. To clarify, host and target are running Arch.

Edit

By request, here is my qmake.conf (that generates mkspec):

include(../common/linux_device_pre.conf)

ELVEES_CFLAGS             = -march=armv7-a -mtune=cortex-a9 -mfpu=neon-fp16 -DLINUX=1
QMAKE_CFLAGS           += $$ELVEES_CFLAGS
QMAKE_CXXFLAGS         += $$ELVEES_CFLAGS 

DISTRO_OPTS += hard-float

QT_QPA_DEFAULT_PLATFORM = eglfs

include(../common/linux_arm_device_post.conf)

QMAKE_INCDIR_EGL        = /mnt/elvees-rootfs/usr/include/EGL
QMAKE_LIBDIR_EGL        = /mnt/elvees-rootfs/usr/lib
QMAKE_INCDIR_OPENGL_ES2 = /mnt/elvees-rootfs/include/GLES2
QMAKE_LIBDIR_OPENGL_ES2 = /mnt/elvees-rootfs/usr/lib

QMAKE_LIBS_EGL          = -lEGL
QMAKE_LIBS_OPENGL_ES2   = -lGLESv2 $${QMAKE_LIBS_EGL}

load(qt_config)

And these are the qt_config options:

./configure \
-opengl es2 \
-device arch-elvees-g++ \
-device-option CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- \
-sysroot /mnt/elvees-rootfs/ \
-opensource \
-confirm-license \
-optimized-qmake \
-release \
-make libs \
-prefix /opt/qt-elvees\
-no-pch \
-nomake examples \
-nomake tests \
-no-xcb \
-eglfs \
-v
DarkMalex
  • 55
  • 1
  • 8
  • I highly recommend that you do this on a raspberry pi with Raspbian. Don't waste your time with the cross-compiler. – The Quantum Physicist Jul 28 '17 at 08:53
  • what mkspec for cross compilation of qt do you use? Add it to your post to make question more clear. – fghj Jul 28 '17 at 09:38
  • @TheQuantumPhysicist Funny thing is, I have about 3 pi's lying around with qt cross-compiled. But the whole point of the project is porting Qt to this **specific** device. So I'm kinda out of options here. But thanks for an advice anyway – DarkMalex Jul 28 '17 at 09:59
  • @fghj Done. Although, I highly doubt that adds anything to the question. My main point of concern is the very first line. Clearly arm-linux-gnueabihf-g++ is launched with --sysroot=/mnt/elvees-rootfs/ so there shouldn't be no problems with linking. But there are – DarkMalex Jul 28 '17 at 10:15

1 Answers1

1

Apparently, adding -no-gcc-sysroot parameter to configure worked.

eyllanesc
  • 235,170
  • 19
  • 170
  • 241
DarkMalex
  • 55
  • 1
  • 8