Anyone have examples of a mpp framework that needs to dynamically link against another framework?

# multiplatform

[basher]

Anyone have examples of a mpp framework that needs to dynamically link against another framework?

[basher]

Trying to do this with various linker opts and having some difficulty

[Kris Wong]

I don't have an example, but I have this working.

[Kris Wong]

I can probably assist

[basher]

Great! I’ve added -framework <lib> and -F<path> to the binary linker opts. Problem is that when I inspect the framework with otool -L, there’s no command added to dynamically link the framework. On top of that, I end up with all of the symbols from that framework in my main framework’s symbol table (causes lookup issues when launch the app)

[Kris Wong]

Is this an objective C framework that you're consuming via cinterop?

[basher]

It’s SQLite bundled into a framework. We use it In the main app, and I need it to link here as well

[olonho]

Is main app in Kotlin?

[svyatoslav.scherbina]

Is your Kotlin framework dynamic or static?

[ribesg]

This may or may not help (group of 2 gists, don’t miss the link) https://gist.github.com/Ribesg/7a2b14841ad91d121bda24b6b1a7a054

[basher]

The mpp framework is dynamic. Would like to dynamically link the SQLite framework

[basher]

My current thought is that the linking happens for the klib, and then klib is packaged into a framework separately, which is why I don’t see the results of my ld flags using otool -l

[Kris Wong]

you will need to link both frameworks into your app

[Kris Wong]

either via pods or embedded binaries

[svyatoslav.scherbina]

there’s no command added to dynamically link the framework.

On top of that, I end up with all of the symbols from that framework in my main framework’s symbol table (causes lookup issues when launch the app)

Could you clarify? It’s not clear how both can happen at the same time.
What do you mean by “lookup issues”?

[basher]

The symbol table for the k/n framework ends up with all of the symbols from the SQLite framework in it (maybe expected). But then because there’s no command added (I.e. otool -l doesn’t show any reference to SQLite), when something in the main app goes to reference a SQLite symbol, it sees it in the K/N framework’s symbol table and errors with a read failure (that symbol isn’t used by the framework, and the framework has no command to load the SQLite framework)

[basher]

sees it in the K/N framework’s symbol table and errors with a read failure (that symbol isn’t used by the framework, and the framework has no command to load the SQLite framework)

This part is a bit speculative, but the error trace strongly suggests this is what’s happening (read error is accurate)

[Kris Wong]

what is the actual error?

[basher]

With this, it links fine (sqlite framework is built at $buildDir/sqlite3.framework). At runtime, it crashes when some other code goes to access a sqlite symbol (specifically a call to sqlite3_collation_needed) that the MPP framework does not use (read failure at 0x0)

binaries {
    framework {
        embedBitcode = 'DISABLE'
        linkerOpts = ["-framework sqlite3", "-F$buildDir"]
    }
}

[Kris Wong]

and you have embedded this framework in your app bundle?

[basher]

yep

[Kris Wong]

i've not seen anything like that before

[basher]

ended up fixing all of my issues by just linking a local dylib (which properly adds the dylib load command to the framework) and then using install_name_tool to update it to a relative path that uses @executable_path