dart:ffi Platform agnostic way to specify native library name for DynamicLibrary.open()

[atsushieno]

Current dart:ffi (I tried with 2.5.2 on linux_x64) simply requires file path at DynamicLibrary.open(). It is good that at least a method has an obvious behavior that does not expect any implicit paths to probe, but this is too barebone for real-world use. What I would expect this function is like, this piece of code works in platform agnostic way:

DynamicLibrary.open('helloworld'); // loads helloworld.dll, libhelloworld.dylib, or libhelloworld.so automatically.

Also, there should be some standard probed paths to look up the library file, with file extensions supplied (.dll / .dylib / .so) and therefore something like DynamicLibrary.open('c') should work.

We have no such problem in Java JNI or .NET P/Invoke.

[mraleph]

/cc @dcharkes

[dcharkes]

We should probably expose https://github.com/dart-lang/sdk/blob/master/tests/ffi/dylib_utils.dart in package:ffi.

And usually we resolve relative to the dart file:

DynamicLibrary ffiTestFunctions = dlopenPlatformSpecific("native_functions",
    path: Platform.script.resolve("native/out/").path);

(source)

[atsushieno]

We very often resolve to libraries that are installed on the system and ffi should work just fine without any ugly hack to probe paths every time. For example it feels stupid to have to either probe paths to or bundle glib, gtk, ALSA, pulseaudio, etc.

[maks]

Has this actually already been implemented?
I just tried on ubuntu 21.04 with Dart 2.13.3 and if I use DynamicLibrary.open('libasound.so.2') it seems to work fine even though libasound is actually located at:

ldd /usr/bin/aplay
        linux-vdso.so.1 (0x00007ffd4fdeb000)
        libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f32c4378000)
...

so I'm guessing that Dart FFI on Linux at least is looking up the actual path to libasound for me in this case?

[dcharkes]

This feature request has been superseeded by:

• ☂️ [vm/ffi] Native assets feature #50565

The native assets feature enables mapping an assetId to a dynamic library name per OS/architecture. Even more so, it lets Dart/Flutter modify the path of the dylib so be what it will be in the shipped app. For example: https://github.com/flutter/flutter/blob/87b8bf646ff5ae0302fcd8737be5e57f0a343309/packages/flutter_tools/lib/src/macos/native_assets_host.dart#L87

Please try out the native assets feature which is available as an experiment.