macOS: Explicitly link to debug version of framework when needed

When Qt is configured for both debug and release, and frameworks are
enabled, we produce two dynamic libraries inside each framework, eg:

 QtCore.framework/QtCore
 QtCore.framework/QtCore_debug

When building an executable against these frameworks, we pass -framework
QtCore, and the resulting executable will have its LC_LOAD_DYLIB load
commands pointing to e.g.:

  @rpath/QtCore.framework/Versions/5/QtCore

When running the executable, the dynamic loader will load the dynamic
library dependencies based on these load commands.

By setting the DYLD_IMAGE_SUFFIX environment variable at runtime to
'_debug', the dynamic loader will prefer the debug versions of each
library inside the frameworks.

Unfortunately the use of an environment variable to choose debug or
release versions leaves room for mismatches between the executable
and the libraries that are loaded. An executable built in debug
mode will at runtime pick up the release versions of the Qt libraries
unless the DYLD_IMAGE_SUFFIX has also been set to match the build
configuration of the executable.

This results in confusing situations such as building your application
in debug mode, and then stepping into Qt code but not getting any
symbols. Qt Creator has an option to run the application with
DYLD_IMAGE_SUFFIX set, but this is not enabled by default due
to the startup cost of loading the Qt debug libraries.

More critically, it results in tests failing when the tests are using
QTest::ignoreMessage to ignore warnings produced by Qt, and these
calls are ifdefed (correctly) inside QT_NO_DEBUG, as the test
(built in debug mode) will then expect warnings from Qt, but those
warnings are not emittet, as the test is run against the release
version of the Qt libraries.

To mitigate this mismatch, we now link the Qt frameworks using
an explicit suffix, just like we would for no-framework builds
on macOS, for debug and release builds on Windows, and for
normal builds on other Unixes, leaving the dependency chain
for the application predictable:

 @rpath/QtCore.framework/Versions/5/QtCore_debug

This also conceptually matches how Xcode builds applications and
frameworks, where it never relies on DYLD_IMAGE_SUFFIX, and instead
uses two separate build directories, one for each configuration.

The change means that Qt Creator will always load the Qt debug
libraries if the application is built in debug mode. For Qt
development this is a good thing, as you expect to be able to
step into Qt code. For our users, the added startup cost can
be mitigated by shipping our binary packages as release-only,
but with separate debug info enabled.

Change-Id: Ib9f1f2dab90ed00b9fb011200e3a69c71955e399
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>

mkspecs/features/qt.prf

@@ -230,7 +230,16 @@ for(ever) {
         QMAKE_FRAMEWORKPATH *= $$MODULE_FRAMEWORKS
         !isEmpty(MODULE_MODULE) {
             contains(MODULE_CONFIG, lib_bundle) {
-                LIBS$$var_sfx += -framework $$MODULE_MODULE
+                framework = $$MODULE_MODULE
+                qtConfig(debug_and_release):!macx-xcode {
+                    platform_target_suffix = $$qtPlatformTargetSuffix()
+                    !isEmpty(platform_target_suffix): \
+                        # The -framework linker argument supports a name[,suffix] version,
+                        # where if the suffix is specified the framework is first searched
+                        # for the library with the suffix and then without.
+                        framework = $$framework,$$platform_target_suffix
+                }
+                LIBS$$var_sfx += -framework $$framework
             } else {
                 !isEmpty(MODULE_LIBS_ADD): \
                     LIBS$$var_sfx += -L$$MODULE_LIBS_ADD

src/corelib/plugin/qfactoryloader.cpp

@@ -117,29 +117,22 @@ void QFactoryLoader::update()
                     QDir::Files);
         QLibraryPrivate *library = 0;
 
-#ifdef Q_OS_MAC
-        // Loading both the debug and release version of the cocoa plugins causes the objective-c runtime
-        // to print "duplicate class definitions" warnings. Detect if QFactoryLoader is about to load both,
-        // skip one of them (below).
-        //
-        // ### FIXME find a proper solution
-        //
-        const bool isLoadingDebugAndReleaseCocoa = plugins.contains(QLatin1String("libqcocoa_debug.dylib"))
-                && plugins.contains(QLatin1String("libqcocoa.dylib"));
-#endif
         for (int j = 0; j < plugins.count(); ++j) {
             QString fileName = QDir::cleanPath(path + QLatin1Char('/') + plugins.at(j));
 
 #ifdef Q_OS_MAC
-            if (isLoadingDebugAndReleaseCocoa) {
-#ifdef QT_DEBUG
-               if (fileName.contains(QLatin1String("libqcocoa.dylib")))
-                   continue;    // Skip release plugin in debug mode
-#else
-               if (fileName.contains(QLatin1String("libqcocoa_debug.dylib")))
-                   continue;    // Skip debug plugin in release mode
-#endif
-            }
+            const bool isDebugPlugin = fileName.endsWith(QLatin1String("_debug.dylib"));
+            const bool isDebugLibrary =
+                #ifdef QT_DEBUG
+                    true;
+                #else
+                    false;
+                #endif
+
+            // Skip mismatching plugins so that we don't end up loading both debug and release
+            // versions of the same Qt libraries (due to the plugin's dependencies).
+            if (isDebugPlugin != isDebugLibrary)
+                continue;
 #endif
             if (qt_debug_component()) {
                 qDebug() << "QFactoryLoader::QFactoryLoader() looking at" << fileName;