From c0188b2dbd7e34b359b091865f19b87bc12d7bd5 Mon Sep 17 00:00:00 2001 From: Alexandru Croitor Date: Mon, 9 May 2022 18:44:02 +0200 Subject: [PATCH] CMake: Fix issue with linking against static library on iOS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently our iOS CMake toolchain file sets the global XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work around a CMake issue regarding usage of object libraries in conjunction with Xcode. The error was The OBJECT library type may not be used for IMPORTED libraries under Xcode with multiple architectures $(CURRENT_ARCH) While this got rid of the error, it introduced a regression where linking an executable against a static library in the same project failed due to the library not being placed in a directory where Xcode expects it to be. clang: error: no such file or directory: '~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a' The actual library is created in Debug-iphoneos/libuntitled4.a Note the -iphoneos suffix, which is related to the EFFECTIVE_PLATFORM_NAME. This could be further worked around by either explicitly setting the library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the end of the project. Both workarounds are not project-friendly. In the mean time CMake got a fix for the original error at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771 which got released with CMake 3.20.0. That was unfortunately not sufficient to remove our initial workaround, because removing it would trigger a different error at generation time CMake Error: Error evaluating generator expression: $ The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake (limited under Xcode with multiple architectures). It is not suitable for writing out elsewhere. Fortunately, another fix landed in CMake 3.21.0 to address that https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161 Because static builds (iOS) require CMake 3.21, with both of these fixes we can now remove our workaround. Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work fine. This also fixes installation of libraries, which also took into account the effective platform name and thus caused a mismatch between the expected output dir and the real one. This reverts 1e1805ed36a932dcb085a1ad3308782a136d477c Pick-to: 6.2 6.3 Fixes: QTBUG-93268 Fixes: QTBUG-95381 Task-number: QTBUG-87198 Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3 Reviewed-by: Jörg Bornemann Reviewed-by: Alexey Edelev --- cmake/QtToolchainHelpers.cmake | 3 --- 1 file changed, 3 deletions(-) diff --git a/cmake/QtToolchainHelpers.cmake b/cmake/QtToolchainHelpers.cmake index f5cf783912b..6a003d3e9b2 100644 --- a/cmake/QtToolchainHelpers.cmake +++ b/cmake/QtToolchainHelpers.cmake @@ -230,9 +230,6 @@ set(__qt_chainload_toolchain_file \"\${__qt_initially_configured_toolchain_file} if(UIKIT) list(APPEND init_platform "set(CMAKE_SYSTEM_NAME \"${CMAKE_SYSTEM_NAME}\" CACHE STRING \"\")") - list(APPEND init_platform "if(CMAKE_GENERATOR STREQUAL \"Xcode\" AND NOT QT_NO_XCODE_EMIT_EPN)") - list(APPEND init_platform " set_property(GLOBAL PROPERTY XCODE_EMIT_EFFECTIVE_PLATFORM_NAME OFF)") - list(APPEND init_platform "endif()") endif() elseif(ANDROID) list(APPEND init_platform