We currently have 2 mechanisms that handle linking of static plugins into executables.

One is used in user projects and when building a Qt repo against already installed dependent Qt packages.
Another when building Qt itself.

The former uses usage requirements genexes, the latter collects linked libs at configure time.

Unfortunately the libs collection is only done at qt_add_executable time (no deferred execution) which means it can miss libs added via qt_internal_extend_target.
https://github.com/qt/qtbase/blob/46438c91f71249d89b17fd80ec0a00cd9166c63e/cmake/QtExecutableHelpers.cmake#L252
If those libs expose static plugins, they would not be linked.

This can be observed when building the qtdeclarative 'qml' app in a top-level static build.
The qml target links to QtGui conditionally via qt_internal_extend_target and because of the above described limitation, no QPA (or any Gui) static plugins will be linked into the app, causing a runtime failure.

This specific failure would not reproduce in a per-repo static build because usage requirements would be used to link the Gui plugins (first approach).

We should check if we can fix the lib collection and plugin linking to be deferred.