dart2native should support C-compatible native dynamic library export

[tats-u]

According to https://dart.dev/tools/dart-compile#subcommands, Dart does not support the export for C-compatible native dynamic library (DLL) and lacks interoperability with languages other than JS.

For example, Dart Sass is difficult to be used by other than JS because as for now. This is why Sass has not been supported by Rust-based JS bundlers (e.g. Turbopack and Rspack). The official implementation of Sass used to be the C++-based LibSass, which is much easier to be used by other languages than JS.

[mraleph]

FWIW Dart Sass has a protocol for out of process embedding (https://github.com/sass/sass/blob/main/spec/embedded-protocol.md) which AFAIK is the recommended way to use Dart Sass from other languages.

While we might look at producing shared libraries this year, there are natural reasons for why APIs of these libraries would never be trivially equivalent to a native C library. The main problem here is Dart's concurrency model based on isolates and built-in event loop - this means exported APIs either have to make embedder aware about these specifics or be asynchronous (so that communication between loaded library and host environment becomes more akin to message passing) or both.

[tats-u]

FWIW Dart Sass has a protocol for out of process embedding (https://github.com/sass/sass/blob/main/spec/embedded-protocol.md) which AFAIK is the recommended way to use Dart Sass from other languages.

This is a good news and made the priority of this issue lower. You do not have to be in a hurry at all. I understood Dart Sass recommends Protobuf instead of C-compatible FFI, and Dart looks difficult to support C-FFI compatible function extern APIs. Go, which uses GC like Dart, looks like support DLL export, but I do not know its details and practicality.