Unsolved Why does configure explicitly avoid calling pkg-config --libs-only-other?
-
Looking at qt_configure.prf, I found configure is explicitly avoiding calling
pkg-config --libs
, but instead callspkg-config --libs-only-L
and--libs-only-l
, thus avoiding--libs-only-other
(see code reference).
I found this was done for some specific reason in this commit.
Q1: What is the rationale behind this?I'm asking out of curiosity and also because it is causing me trouble:
I'm trying to cross-compile Qt5.15 for a Raspberry Pi 3 using the Broadcom libraries they renamed to libbrcmEGL, libbrcmGLESv2 and so on (long story), but instead of using symlinks like here I wanted to see if I could get pkg-config to work.
The troublemakers are egl.pc (linked to /opt/vc/lib/pkgconfig/brcmegl.pc) and the bcm_host.pc it depends on, both listed at the bottom for your convenience.If I run
./configure
, this test fails:Trying source 0 (type pkgConfig) of library egl ... + PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --exists --silence-errors egl + PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --modversion egl > 10 + PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --libs-only-L egl > -L/opt/qt5pi/sysroot/opt/vc/lib + PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --libs-only-l egl > -lbrcmEGL -lbrcmGLESv2 -lbcm_host -lvchostif -lbcm_host -lvcos -lvchiq_arm + PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --cflags egl > -DUSE_VCHIQ_ARM -I/opt/qt5pi/sysroot/opt/vc/include -I/opt/qt5pi/sysroot/opt/vc/include/interface/vmcs_host/linux -I/opt/qt5pi/sysroot/opt/vc/include/interface/vcos/pthreads -I/opt/qt5pi/sysroot/opt/vc/include -I/opt/qt5pi/sysroot/opt/vc/include/interface/vmcs_host/linux -I/opt/qt5pi/sysroot/opt/vc/include/interface/vcos/pthreads + cd /opt/qt5pi/build/config.tests/egl && PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /opt/qt5pi/build/qtbase/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" "QMAKE_CFLAGS += --sysroot=/opt/qt5pi/sysroot" "QMAKE_CXXFLAGS += --sysroot=/opt/qt5pi/sysroot" "QMAKE_LFLAGS += --sysroot=/opt/qt5pi/sysroot" -early "CONFIG += cross_compile" 'QMAKE_USE += egl' 'QMAKE_LIBS_EGL = -L/opt/qt5pi/sysroot/opt/vc/lib -lbrcmEGL -lbrcmGLESv2 -lbcm_host -lvchostif -lbcm_host -lvcos -lvchiq_arm' 'QMAKE_INCDIR_EGL = /opt/qt5pi/sysroot/opt/vc/include /opt/qt5pi/sysroot/opt/vc/include/interface/vmcs_host/linux /opt/qt5pi/sysroot/opt/vc/include/interface/vcos/pthreads /opt/qt5pi/sysroot/opt/vc/include /opt/qt5pi/sysroot/opt/vc/include/interface/vmcs_host/linux /opt/qt5pi/sysroot/opt/vc/include/interface/vcos/pthreads' 'QMAKE_DEFINES_EGL = USE_VCHIQ_ARM' /opt/qt5pi/build/config.tests/egl + cd /opt/qt5pi/build/config.tests/egl && MAKEFLAGS= /usr/bin/make clean && MAKEFLAGS= /usr/bin/make . . . > /opt/raspiToolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/7.5.0/../../../../arm-linux-gnueabihf/bin/ld: /opt/qt5pi/sysroot/opt/vc/lib/libvchostif.a(vc_vchi_dispmanx.c.o): undefined reference to symbol 'sem_destroy@@GLIBC_2.4' > /opt/qt5pi/sysroot/lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO aus der Kommandozeile fehlt
The reason becomes clear if I run
pkg-config --libs egl
:-L/opt/qt5pi/sysroot/opt/vc/lib -lbrcmEGL -lbrcmGLESv2 -lbcm_host -lvchostif -lbcm_host -lvcos -lvchiq_arm -pthread
As you see in the configure log,
-pthread
gets ommitted. If I run the test manually and append-pthread
toQMAKE_LIBS_EGL
, the test succeeds.
Q2: So if this is necessary for the test to compile, why does configure explicitly strip it away? And if this is intended, where would you tell configure / the egl test to use-pthread
instead?
Maybe thebcm_host.pc
is just wrong? However, adding-pthread
to Cflags also just gets skipped:+ PKG_CONFIG_SYSROOT_DIR=/opt/qt5pi/sysroot PKG_CONFIG_LIBDIR=/opt/qt5pi/sysroot/usr/lib/pkgconfig:/opt/qt5pi/sysroot/usr/share/pkgconfig:/opt/qt5pi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig /usr/bin/pkg-config --cflags bcm_host > -DUSE_VCHIQ_ARM -pthread -I/opt/qt5pi/sysroot/opt/vc/include -I/opt/qt5pi/sysroot/opt/vc/include/interface/vmcs_host/linux -I/opt/qt5pi/sysroot/opt/vc/include/interface/vcos/pthreads Note: Dropped compiler flags '-pthread'.
I know I can specify
QMAKE_LIBS_EGL
and so on via mkspecs / qmake.conf directly, I have done so and it does work. I'm still curious how one would make it work via pkg-config, though.egl.pc:
prefix=/opt/vc exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: brcmEGL Description: Fake brcmEGL package for RPi Version: 10 Requires: bcm_host Libs: -L${libdir} -lbrcmEGL -lbrcmGLESv2 -lbcm_host -lvchostif Cflags: -I${includedir} -I${includedir}/interface/vmcs_host/linux \ -I${includedir}/interface/vcos/pthreads
brm_host.pc:
prefix=/opt/vc exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: bcm_host Description: Broadcom VideoCore host API library Version: 1 Libs: -L${libdir} -lbcm_host -lvcos -lvchiq_arm -pthread Cflags: -I${includedir} -I${includedir}/interface/vmcs_host/linux -I${includedir}/interface/vcos/pthreads -DUSE_VCHIQ_ARM
-
Hi and welcome to devnet,
That's an interesting question and a pretty good analysis. However, this is rather a user forum. You should bring that question to the interest mailing list. You'll find there Qt's developers/maintainers.