We have build issues for iOS `Release` Builds sinc...
# multiplatform
m
We have build issues for iOS
Release
Builds since upgrading to Kotlin 2.1.0 with SKIE 0.10.0. I created a StackOverflow question. Anybody an idea? https://stackoverflow.com/questions/79358761/kmm-app-with-skie-ios-build-with-releaseconfiguration-fails-when-linking-un
t
Hi, I replied to your SKIE issue yesterday if you could provide a reproducer project so we can debug the issue.
If not, please set your KMP framework to static and then try compiling in Xcode. It should hopefully fail linking in Xcode and might have more information. If it doesn't, then in Xcode you should be able to add
-v
to other linker flags.
m
Hey Tadeas, I read it. But it’s not that easy, because we have a very big project with Unity integration etc., but on the long way I will do it.
t
Okay, please try the steps I mentioned above to see what it says
1
Did you try disabling SKIE
skie { isEnabled = false }
to see if it's SKIE or Kotlin 2.1.0?
m
Disabling SKIE breaks the whole project
t
Could you: 1. make sure dynamic framework is enabled 2. run just the
link
Kotlin Gradle task for the Release configuration 3. if it fails, disable SKIE and run it again
m
Building with
-v
linker flag doesn’t provide any additional useful information
t
The compilation in Xcode without SKIE is supposed to fail, we need to know whether the linking succeeded
You can also try: 1. make sure dynamic framework is produced 2. disable SKIE 3. compile in Xcode
And then let me know if the Kotlin Gradle task succeeds
m
1. Producing dynamic framework:
Debug
Build is successful,
Release
build fails 2. Disabling SKIE produces a lot of errors (as mentioned above)
Run the build again (dynamic framework) with
--stacktrace
and got the following error:
t
Sounds like that’s a Kotlin issue not SKIE
What was the result when you tried running the Gradle link task with SKIE disabled?
t
No this is compiling from Xcode, I mean when you run the Gradle task from terminal
m
You mean like this:
./gradlew --stacktrace --debug :shared:linkReleaseFrameworkIosArm64
?
t
Yeah
m
Only tried this with SKIE, but will now try without
t
How did it go?
j
Did you try the ld_classic flag? I think it's worked for most people?
m
Yes, with
-ld_classic
the
Release
build works and via Xcode the app runs. Building on our MacMini CI the
Release
build is successful but app crashes on startup with following Crashlytics error:
Ok, I removed now the initialization of CrashKiOS in our AppDelegate
CrashReporting.shared.enable()
and
Release
Build with
-ld_classic
linker and dynamic shared framework builds and starts successful 😮
Summary: Could not solve
clang: error: unable to execute command: Bus error: 10
for
Release
builds with static shared framework :( Switched then to dynamic framework by removing
isStatic = true
and got the following error:
Copy code
The /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld command returned non-zero exit code: 138.
output:
ld: warning: ignoring duplicate libraries: '-ldl', '-lobjc'

> Task :iosFramework:linkReleaseFrameworkIosArm64 FAILED
Found this issue in Kotlin issue tracker: https://youtrack.jetbrains.com/issue/KT-70202/Xcode-16-Linker-fails-with-SIGBUS-compiling-XCTest-based-tests As suggested in KT-70202, I added
linkerOpts("-ld_classic")
and the release build was building successful. Then run into the issue that the release build (distributed via Firebase AppDistribution) was crashing on app start. Found out that this was caused by CrashKiOS framework, probably because CrashKiOS has issues with dynamic frameworks, see issue here and still not fixed in latest version 0.9.0: https://github.com/touchlab/CrashKiOS/issues/69 Than removed CrashKiOS initialization
CrashReporting.shared.enable()
in
AppDelegate
and finally the
Release
build successfully builds local, on CI and starts up with no issues. So I guess, it is no SKIE issue, but Kotlin 2.1.0 issue.
t
Just to doublecheck, with SKIE disabled it still failed to compile?
m
Yes, was not able to compile with SKIE disabled, neither via Xcode, nor via command line
t
Good to know, thanks!
156 Views