Why does configure explicitly avoid calling pkg-config --libs-only-other?

codecepts

Looking at qt_configure.prf, I found configure is explicitly avoiding calling pkg-config --libs, but instead calls pkg-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 to QMAKE_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 the bcm_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

SGaist

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.