Details
-
Bug
-
Resolution: Done
-
P2: Important
-
None
-
6.0
-
f3c7d22dd04afe8d889585fb5d6426f3d4591e74 (qt/qtbase/dev)
Description
qmake does not consider libraries in /usr/local to be system libraries on macOS, and thus doesn't link to them. It only links to libraries in the sdk (afaik).
Also in qmake land pkg-config is by default disabled.
This is in contrast to cmake which considers /usr/local as a system prefix when looking for libraries or files via find_library and find_path.
In addition pkg-config is by default enabled in cmake.
This causes a difference to qmake land, that the Qt build picks up various things in /usr/local which are installed via homebrew, and causes linker warnings like
ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/Cellar/glib/2.62.3/lib/libglib-2.0.dylib ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/lib/libpng.dylib ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/lib/libfreetype.dylib
We should align CMake to do the same things as qmake.
Proposed solution is to fake disable pkg_config by setting PKG_CONFIG_EXECUTABLE to a non-existent path.
Complications are: how to detect this decision only while building Qt, and taking into account the feature value.
And remove /usr/local/lib as a prefix by adding it to CMAKE_SYSTEM_IGNORE_PATH (it's initially added by CMake's platform module file to CMAKE_SYSTEM_PREFIX_PATH).
This should probably be done via our generate toolchain file, and also allow for the user to opt out somehow.
Attachments
Issue Links
- relates to
-
QTBUG-85240 Building examples with qmake / cmake using Qt 6.0.0 snapshot fails
- Closed
- resulted in
-
QTBUG-85357 Heap use after free in tst_qsqlquery.cpp
- Closed
-
QTBUG-85568 harfbuzz header files included from wrong path
- Closed