https://kotlinlang.org
Join Slack
Am trying to convert project to use dynamic linking.....I've followed <https://crashkios.touchlab.co...
# touchlab-tools
j
Am trying to convert project to use dynamic linking.....I've followed https://crashkios.touchlab.co/docs/crashlytics/#step-3---setup-dynamic-linking-optional (added 
co.touchlab.crashkios.crashlyticslink
plugin) but still getting following. Are there any other steps needed? Is it possible to add as linker option etc in Xcode?
Copy code
Undefined symbols for architecture arm64:

  "_FIRCLSExceptionRecordNSException", referenced from:
      _co_touchlab_crashkios_crashlytics_tryFIRCLSExceptionRecordNSException_wrapper136 in libco.touchlab.crashkios:crashlytics-cinterop-crashlytics-cache.a[2](libco.touchlab.crashkios:crashlytics-cinterop-crashlytics-cache.a.o)
....
k
When? Build or test?
j
build
k
We talked about this internally today.
The whole problem of 3rd-party linking.
It's a huge pain and never seems to end
For Crashlytics/Bugsnag, we'll probably move code out into Swift/iOS vs cinterop. "How" is TBD, but this situation is a source of endless issues.
j
project is using convention plugin approach fwiw but think I've setup that properly to use 
co.touchlab.crashkios.crashlyticslink
plugin but maybe some issue there
k
Well, I'm not really an expert on convention plugins, so tough to comment on that.
To check it directly, you'd need to get the build log and look for the 
ld
statement, and/or get the 
-linker-options
passed to the compiler.
j
there's nothing that can be added to "Other Linker Flags" etc (as done with say sqllite3?
k
If that's the Xcode build, then maybe a different story. I was assuming this was from gradle.
j
I had tried with gradle as per those instructions
had just wondered if maybe a way to address with Xcode
I had to add 
-lsqllite3
for example when switching from static
k
The Kotlin compiler needs to assemble the framework, and for dynamic frameworks, it requires either all links to be satisfied, or you need to tell it (basically) "don't worry about this". That's what crashlyticslink does.
j
ah, ok
k
That particular flag is 
-U _FIRCLSExceptionRecordNSException
You can try adding that where you add 
-lsqlite3
j
trying that now
k
We've had other issues, though. For some builds, when whatever happens later happens (app thinning, etc), some builds have had various symbols stripped, etc. Crashlytics for CrashKiOS tried to sidestep everything by dynamically calling the Crashlytics iOS library rather than using cinterop, but depending on what you directly reference in Swift (we think) app thinning may decide you don't need it.
This is a general problem with any native library. Directly in an app project, it's not so bad, but publishing Kotlin libraries that depend on native libraries that you aren't actually shipping with the Kotlin library is a seemingly bottomless pit of suffering.
j
tried this but still getting same error for some reason
I'll dig a bit deeper now that I know what it's trying to do
k
Well, I'd try and build the framework with Gradle from the command line. If that works, then it's an Xcode-world thing. If that doesn't, it's a Kotlin/Gradle world thing.
j
yeah, I guess this needs to be done at gradle level
I found another post that suggested following (in gradle)
Copy code
freeCompilerArgs = listOf(
                "-linker-options",
                "-U _FIRCLSExceptionRecordNSException " +
                        "-U _OBJC_CLASS_\$_FIRStackFrame " +
                        "-U _OBJC_CLASS_\$_FIRExceptionModel " +
                        "-U _OBJC_CLASS_\$_FIRCrashlytics"
            )
k
That's the manual way to do it, before 
crashlyticslink
. You should try that. The last 3 aren't needed because of the dynamic calls, but leaving them on shouldn't hurt.
j
ok, getting following etc now so guess need to add sqlite3 to those linker options here
Copy code
Undefined symbols for architecture arm64:
  "_sqlite3_bind_blob", referenced from:
      _co_touchlab_sqliter_sqlite3_sqlite3_bind_blob_wrapper69 in shared.framework.o
....
k
Yeah.
j
that worked, thanks
must have been some issue with way I setup that plugin but that linker-options is probably cleaner anyway in setup here
k
Good luck. I'm quite partial to static frameworks. Usually simpler.
j
build speed is main reason I'm trying this
k
Ah
j
there's good few modules in project and I think build should be faster but will do some proper comparisons tomorrow
t
I wouldn't expect Kotlin build to be faster, if anything it should be slower because it needs to link. But if you change the Swift code in Xcode often without changing the KMP code, then dynamic would help because you don't have to relink the whole KMP each time
j
Thanks @Tadeas Kriz....have you seen any other advantages of dynamic (particularly given it's the default).....or do you generally try to use static?
54 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by