1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

CMake: Fix issue with linking against static library on iOS

Browse Source 
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:
    $<TARGET_OBJECTS:Qt6::Quick_resources_1>
  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 <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This commit is contained in:
Alexandru Croitor 2022-05-09 18:44:02 +02:00
parent a3917126e8
commit c0188b2dbd
1 changed files with 0 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
cmake/QtToolchainHelpers.cmake
View File

@ -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