Handling p/invokes for different platforms and discussions about dllmap

[akoeplinger]

Right now, coreclr has no good way to handle the differences between platforms when it comes to p/invoking native libraries.

E.g. imagine I want to call an openssl function, on Unix the library is called libssl.so/dylib but on Windows it is libeay32.dll (there are countless other examples, e.g. libz.so vs zlib1.dll).

corefx "solves" this by conditionally compiling the p/invoke code for each platform with the correct library name. This seems like a major organizational overhead though and is brittle when new platforms are added.

Mono does two things to make this much easier:

1. It automatically probes for variations of the string passed to DllImport, e.g. if I specify DllImport("myFoo") it tries myFoo.dll, myFoo.so, libmyFoo.so and so on. In the happy case this is enough to find the library on all the platforms.
2. DllMap: this is for cases where the library name is just too different, or if only a certain function should be redirected, or only on some specific platforms.

In my opinion, coreclr should implement something along those lines. I know that using DllMap 1:1 is not really possible since there's no System.Configuration stack in .NET Core, but it should at least guide an alternate implementation.

What do you think?

edit I proposed adding DllMap attributes in https://github.com/dotnet/coreclr/issues/930#issuecomment-100675743 :

[assembly: DllMap("foo", "foo.dll", OSName.Windows)]
[assembly: DllMap("foo", "libfoo.dylib", OSName.OSX)]
[assembly: DllMap(Dll="foo", Target="libfoo.so", OS=OSName.Linux)]
[assembly: DllMap(Dll="dl", Name="dlclose", Target="libc.so", OS="FreeBSD")]

[jkotas]

cc @stephentoub

Related to #4032

[janhenke]

myFoo.so should never exist. All tools I know enforce the naming convention of having a lib prefix for every shared library. On the other hand things can be even more complicated by the ABI version suffix, i.e. libFoo.so.0.6.

[akoeplinger]

@janhenke in theory yes, Mono just tries a few of the combinations that make sense.

[sergiy-k]

This is an interesting problem to tackle. I’m curious what is your experience with DllMap? What works well and what doesn’t?

[davidfowl]

As long as we keep the assembly load context hook so that the host can decide how this works then I'm happy. I think the core for should try to reduce as much policy/configuration as it can ootb (this reeks of binding redirects).

Doesn't the host also let you configure paths for dll imports? Maybe that can be extended to allow probing for more stuff (different extensions etc).

[akoeplinger]

@sergiy-k I'm not really an expert on DllMap, but I haven't had too many problems in my limited use. The main problem I see is where to put the stuff (.config files don't exist anymore in this new world). I'd be happy with a first step that just probes for different variations if a lib can't be found by the verbatim string.

@davidfowl how would the application hook into that?

[davidfowl]

One more thing, some of the libs in aspnet avoid dll import and instead load libraries using another A library provided by the dnx to help locate the native lib:

https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNet.Server.Kestrel/Networking/PlatformApis.cs

And the usage:

https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNet.Server.Kestrel/Networking/Libuv.cs

[davidfowl]

How would the app handle it? I have no idea. I don't see the core clr as an application model. I see it as a building block with configurable policy and a nice hosting API.

There will be a way to express native dependencies in project.json and in nuget packages. The dnx host will hook the event and do something clever :)

[OtherCrashOverride]

The main thing to keep in mind for this is compatibility.

This means the solution needs to assume you are running a compiled .Net application (.exe/.dll) and that it has hard-coded references to library names that work on windows. Adding platform specific class abstractions will not work in this scenario. The .Net binary is already compiled and source may not be available.

A good real world example is calls into the C runtime to "memcpy". The library name is entirely different on windows than other platforms "msvcrt.dll" versus "libc.so". Name mangling wont fix it and hard coded substitution presents a maintenance burden to keep up with every new runtime version release.

With regard to name mangling, I would prefer to see a single, known and documented substitution take place: "MyFoo.dll" -> "libMyFoo.so". Tying more than one substitution as Mono does can open the door to file name collisions. The main issue present with this approach is case sensitivity. .Net code assumes a windows platform and is not case sensitive as unix is. So "MyFoo.dll" and "myfoo.dll" are not the same.

Taking all the above into account, the only realistic solution is a "DllMap" style configuration file that can be added alongside an already compiled binary.

For completeness, the proper way to specify a DllImport is to name only the library file name without extension. So the above example would be written as [DllImport("MyFoo")]. The platform specific suffix (.dll/.so) is added by the runtime. This would imply the correct behavior would be for the runtime to also add the platform specific prefix (lib). Anything beyond this would need to be specified by the "DllMap" style solution.

[OtherCrashOverride]

One other comment regarding .so versioning: This is usually solved by providing a symlink to the explicit verison named library.

[Joe4evr]

.Net code assumes a windows platform and is not case sensitive as unix is.

I do believe this isn't the case. .Net is perfectly case-sensitive, but it's only the underlying filesystem implementation in Windows that's insensitive. I'm also pretty sure that the CLR doesn't assume anything, and even if it did, CoreCLR is built from the ground up to not assume these kinds of platform-specific things.

[akoeplinger]

@OtherCrashOverride

This means the solution needs to assume you are running a compiled .Net application (.exe/.dll) and that it has hard-coded references to library names that work on windows. Adding platform specific class abstractions will not work in this scenario. The .Net binary is already compiled and source may not be available.

This isn't a concern as existing assemblies don't work on .NET Core anyway and need to be recompiled.

I agree that whatever the solution is it shouldn't rely on too much magic and be properly documented.

[OtherCrashOverride]

Let me expand that a bit:
[The authors of existing] .Net code assumes [operation on] a windows platform and [with a file system that] is not case sensitive as unix is.

This is specific to pre-existing .Net binaries that are authored by 3rd parties for which the option of recompiling is not available. Its the reason Mono implemented "DllMap".

[OtherCrashOverride]

Pre-existing binaries are not limited to just legacy. Its possible for someone to author new .Net Core assemblies that P/Invokes the C runtime today. Its also possible that this assembly is 3rd party and released without code.

[xanather]

Would it be possible to allow the library/module name of DllImport to permit a static readonly allocation somehow? That way we can point to where the library should be loaded in a class's static constructor. Right now attributes parameters are compile time things so it would be a problem. However it would avoid the need of an external .config file which apparently does not exist in .NET Core.