Why does native_toolchain_rust insist on staticlib?

[knopp]

In all cases I am interested in the native asset builder will be happy with a dylib, I don't quite understand why it is necessary for native_toolchain_rust to produce a staticlib as well?

[GregoryConrad]

Flutter sometimes requests it based on the provided link mode:

native_toolchain_rust/native_toolchain_rust/lib/src/build_runner.dart

Line 56 in aeda048

final CodeConfig(:targetOS, :targetTriple, :linkMode) = codeConfig;

[knopp]

Can you give me an example where you'd get LinkModePreference.static in the code config? I'm having trouble understanding how the linking mode decision could come from anywhere else than the package itself.

Now there is possibly a valid reason for building static lib in case you want to link the library yourself, but that should be an opt-in argument in the builder and shouldn't warrant creating a static lib on every build.

[GregoryConrad]

It’s coming from Flutter itself—depending on the platform/build options, Flutter provides the build hook with what link option is preferred (or must be used in some cases). Would have to look into the flutter tool source code to figure out how it determines what to pass down.

This feels a little like an XY problem—what problem are you trying to solve here that static libs are creating?

[knopp]

I think static library is harmless, it's just redundant and I don't like redundant things happening during the build.

On every platform Flutter will expect a dynamic library. Static linking is not yet supported (dart-lang/sdk#49418) and would need a lot more work to support. In general a native asset providing static library alone is pretty useless. Flutter will still need to know how to link it (i.e. linker flags, dependency frameworks and libraries) and as far as I can tell there is no machinery in place to facilitate any of that.

[GregoryConrad]

Gotcha. If you wanna make a PR that skips building the static/dynamic lib when the other mode is selected, that’s something I’m fine with having here

[knopp]

I think maybe a PR to stop enforcing the staticlib in cargo.toml when flutter doesn't ask for one?

[GregoryConrad]

If it’s possible I’d rather just use some sort of CLI flag to tell cargo to not build the static/dynamic lib when the other is in the LinkModePreferences. That way we remain forwards compatible if/when flutter supports static libs

[knopp]

I don't think being "forward compatible" is actually a feasible thing here. Even if Flutter supported static linking tomorrow it wouldn't mean that things would just work out of box. The package would still need to let Flutter know how to link it and the Dart code would need to know that it should load a completely different library.

[GregoryConrad]

Ok, that's fine then. Skipping the check that ensures a staticlib is created via the Cargo.toml options should be fine