[DllImport] fails despite the DLL is already loaded

[Const-me]

Found on ARM64 Alpine Linux.

Only tested with .NET 6 but I would expect the bug to affect the rest of the Alpine Linux runtimes too.

Steps to reproduce

Use gcc to compile a C DLL which exports a function. Place the compiled DLL into different folder, such as linux-musl-arm64 subfolder.

Use the following code to load it from absolute path:

[DllImport( "libdl" )]
static extern IntPtr dlopen( [In, MarshalAs( UnmanagedType.LPUTF8Str )] string fileName, int flags );
const int RTLD_NOW = 0x002;

string iLoadLibrary.fileName( string dll ) => $"lib{ dll }.so";

void iLoadLibrary.load( string dll )
{
	IntPtr handle = dlopen( dll, RTLD_NOW );
	if( handle != IntPtr.Zero )
		return;
	throw new ApplicationException( $"dlopen failed to load { Path.GetFileName( dll ) }" );
}

In another class, consume the function exported from the DLL with [DllImport] attribute.

In the main function, call iLoadLibrary.load with absolute path to the *.so file, then call the imported function.

Compile and run the .NET app.

Expected Behavior

Should work like on the rest of the platforms (Windows, non-Alpine Linux including ARM)

Actual Behavior

Exception saying it’s unable to find my DLL, despite already loaded into the current process with dlopen.

Couple more notes.

I did try to copy the DLL into the same location where the C# DLL is, worked fine that way. Can’t do that in production because I support multiple architectures, and for security reasons the process does not have permissions to write its own binaries.

If you don’t know how to enumerate loaded native DLLs on Linux, read this. BTW, that’s how I’m detecting musl libc on Linux, by looking for the loaded ld-musl-* DLL.

[huoyaoyuan]

I don't know if the behavior is expected, but as a workaround you may use the AssemblyLoadContext.Default.ResolvingUnmanagedDll event to return the loaded library.

[Const-me]

@huoyaoyuan Workarounds do exist. Personally, I have used the SetDllImportResolver method.

Still, the whole point of .NET runtime is to provide a good enough abstraction over the underlying CPUs and operating systems.
Manually calling LoadLibrary worked for decades with [DllImport], before .NET Core was even written. It works in .NET Core too, Linux included, here's a non-trivial demo. Just not the Alpine Linux, for some reason.

[am11]

@Const-me, with .NET 6 on Alpine Linux 3.15 (arm64), this script prints Hello world!:

#!/usr/bin/env ash

cd /tmp
gcc -xc -shared -o libhello.so -fPIC - <<EOF
#include <stdio.h>
void say_hello(void)
{
     printf("Hello world!\n");
}
EOF

cd ~
dotnet new console -n issue-58601 > /dev/null
cd issue-58601
cat > Program.cs <<EOF
using System.Runtime.InteropServices;

IntPtr libHandle = load("/tmp/libhello.so");
IntPtr sayHelloSymbol = dlsym(libHandle, "say_hello");
SayHelloDelegate sayHello  = Marshal.GetDelegateForFunctionPointer<SayHelloDelegate>(sayHelloSymbol);

if (sayHello is not null) sayHello();
else Console.WriteLine("failed!");

[DllImport( "libdl" )]
static extern IntPtr dlopen( [In, MarshalAs( UnmanagedType.LPUTF8Str )] string fileName, int flags );

[DllImport( "libdl" )]
static extern IntPtr dlsym(IntPtr handle, string symbol);

IntPtr load( string dll )
{
    const int RTLD_NOW = 0x002;
    IntPtr handle = dlopen( dll, RTLD_NOW );
    if( handle != IntPtr.Zero ) return handle;

    throw new ApplicationException( $"dlopen failed to load { Path.GetFileName( dll ) }" );
}

delegate void SayHelloDelegate();
EOF

dotnet build > /dev/null
bin/Debug/net6.0/issue-58601

Does it work in your environment?

[AaronRobinsonMSFT]

@Const-me Have you been able to confirm what @am11 found?

[Const-me]

@AaronRobinsonMSFT I’m not willing to bind functions manually, I’m consuming more than 300 of them, from 15 DLLs. I want [DllImport] to work consistently on all platforms.

Currently, I’m calling NativeLibrary.SetDllImportResolver and [DllImport] works afterwards.

Still, the software is large and has many DLLs both managed and native, so the workaround causes pages of boilerplate code. I would rather not do that.