Uncovered while working on https://codereview.qt-project.org/c/qt/qtquick3d/+/282389/31
Sample failure log:

https://testresults.qt.io/coin/integration/qt/qtquick3d/tasks/web_qt_qtquick3d_1586425297572

https://testresults.qt.io/coin/logview/qt/qtquick3d/7423a56538e3d67779c2af031ac868237ecf4848/LinuxopenSUSE_15_0x86_64LinuxopenSUSE_15_0x86_64GCCqtci-linux-openSUSE-15.0-x86_64-3a30a4/e52f93ce7b9fbba90c597d114668a9645d02de6c/build_1586425309

Order of static libraries matters when using the GNU ld linker on linux, and because something fishy is going on with how we make Gui plugins depend on Gui, and Gui depend on Gui plugins, the linker static lib order gets messed up somehow, and thus causes undefined symbol errors at link time.

Can be reproduced with an app that depends on Qt::Gui and Qt::OpenGL in a more simplified manner (small project will be attached shortly)

EDIT:
Upstream CMake issue at https://gitlab.kitware.com/cmake/cmake/-/issues/20604 the minimal project can also be found there.

The minimal project involving qt looks like this:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(use_static_qt6_quick LANGUAGES CXX)

set(CMAKE_PREFIX_PATH "/path/to/static_qt6_prefix")
find_package(Qt6 REQUIRED COMPONENTS Quick)

set(CMAKE_CXX_STANDARD 14)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} PRIVATE
    Qt6::Gui
    Qt6::OpenGL
    )
qt6_import_plugins(${PROJECT_NAME} NO_DEFAULT
    INCLUDE Qt::QXcbIntegrationPlugin
)

# main.cpp
int main() {return 0;}

It appears that this is expected behavior, and that it's the project responsibility to fix it with LINK_INTERFACE_MULTIPLICITY.

But because what we're doing is wrong in the first place (why have target dependency cycles, if there is no cycle in the underlying .cpp code), that's not really the proper fix.