Can't build xcframework success

[crablife]

I want to build iOS xcframework, but it's fail with following error message

❌ ld: library not found for -lmbgl-core
❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

The following build commands failed:
Ld maplibre/platform/ios/build/ios/ArchiveIntermediates/dynamic/IntermediateBuildFilesPath/ios.build/RelWithDebInfo-iphoneos/dynamic.build/Objects-normal/armv7/Binary/Mapbox normal armv7 (in target 'dynamic' from project 'ios')

I have tried several Xcode version(14.1, 13.4.1, 13.1), but it doesn't work.
My Mac OS version is "Monterey 12.6.1"
Xcode version is "14.1"
And my Mac is M1 chip

The build command I inputed was

1. cd platform/ios
2. make iproj CI=1
3. make xcframework BUILDTYPE=Release

[louwers]

Thanks for the report. I am able to reproduce this locally.

[roblabs]

I am also able to reproduce on Big Sur with Xcode 13.2.1. The scheme that builds for UI Tests, iosapp, builds and works fine.

Looking at the log file, within.cpp fails to build. In a Slack chat @louwers mentioned GitHub Actions that build the XCFramework. I went to check those and release hasn't ran for a month and pre-release hasn't ran for a couple of years on GitHub.

I just kicked off both of those manually to see what they will yield. Here is where the GitHub Actions can be verified.

• https://github.com/maplibre/maplibre-gl-native/actions

These are the two actions to be monitored when there status is updated at GitHub:

• [❌] ios-release
• ios-pre-release

---

failure in target 'mbgl-core' src/mbgl/style/expression/within.cpp

** ARCHIVE FAILED **


The following build commands failed:
	CompileC /Users/roblabs/Library/Caches/XCSBuilder/Bots/0a0160914c83b73de4c77f2f650006b1/Source/maplibre-gl-native/platform/ios/build/ios/build/mbgl-core.build/Debug-iphonesimulator/Objects-normal/i386/within.o /Users/roblabs/Library/Caches/XCSBuilder/Bots/0a0160914c83b73de4c77f2f650006b1/Source/maplibre-gl-native/src/mbgl/style/expression/within.cpp normal i386 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'mbgl-core' from project 'Mapbox GL Native')
(1 failure)

# print Mac OS X operating system version information
sw_vers
ProductName:	macOS
ProductVersion:	11.7.1
BuildVersion:	20G918

# Print operating system name
uname -a
Darwin nullisland.local 20.6.0 Darwin Kernel Version 20.6.0: Thu Sep 29 20:15:11 PDT 2022; root:xnu-7195.141.42~1/RELEASE_X86_64 x86_64

# Xcode version & path
/usr/bin/xcodebuild -version
Xcode 13.2.1
Build version 13C100

[louwers]

@roblabs ios-release runs though it seems (only fails because the tag has already been released).

[roblabs]

mbgl/style/expression/within.cpp is defined once in the CMake files. That seems fine. My other guess would be to investigate if or when the CMake files were last refactored.

• https://github.com/search?q=repo%3Amaplibre%2Fmaplibre-gl-native+within.cpp+language%3ACMake&type=code&l=CMake

[louwers]

I tried a lot of things to fix this, including increating the minimum deployment target to iOS 12, removing and re-adding the libraries to link in Xcode (Stack overflow reported that this sometimes helps), set "build active active architecture only" to NO. All to no avail.

Just tried again on the macOS runner which is using macOS Montery (12.5.1) and Xcode 14.2. Selecting the dynamic scheme and "Any iOS Device" as target, then selecting Product > Archive works (as well as creating an archive through xcodebuild).

[louwers]

OK I think I finally found the issue: CMake 3.24 works while CMake 3.35 does not.

Edit: this may be it: https://cmake.org/cmake/help/latest/policy/CMP0142.html#policy:CMP0142

[roblabs]

Switching cmake versions worked locally for me as well. We'll have to decide on either creating a dependency for [email protected] or fixing up due to the changes in the link above.

Good catch @louwers

[ntadej]

The policies can be set conditionally as you know which version of CMake you run with. So I'd set the policy accordingly for the versions of CMake when it appeared (or fix our config that the policy is not needed).

It seems though that they reverted it in 3.36, but we should not rely on that.

[louwers]

I tried setting the policy but that did not fix the issue for me.

[ntadej]

Did you do a full rebuild?

[louwers]

Yes.

We have a lot of checked in Xcode files but we also partly generate the Xcode config with CMake. It is a bit hard to debug.

[ntadej]

I can investigate but not before the weekend.

[louwers]

Note that it is still possible to create an XCFramework with Bazel. (After #806 is merged).

I am not very happy with the setup of CMake + checked in Xcode files + Makfile + scripts + xcodebuild on the iOS side. The Bazel setup seems much cleaner, in part thanks to much better iOS support.

[ntadej]

I will be a bit provocative and say, why not CMake-only 😊

I think we should really aim in that direction.

[louwers]

Because CMake support for iOS is lacking. It cannot build XCFrameworks for example.

[ntadej]

Really? You still generate the Xcode project and then you can do anything with it. Do XCFrameworks require some very special configuration to be made?

[louwers]

Generating the entire Xcode project with CMake and getting rid of the checked in Xcode files is probably a big improvement already. But I am not sure if it is feasible. I have to look more into it #737

[louwers]

We have overhauled the build config.

Please try out build instructions in the pre-release thread.