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.