Hardcoded DllImportResolver always chooses libclang 3.5

[kekekeks]

Ubuntu 18.04

Installed packages:

libclang1-6.0:amd64: /usr/lib/llvm-6.0/lib/libclang.so.1
libclang1-3.6:amd64: /usr/lib/llvm-3.6/lib/libclang.so.1
libclang1-3.4:amd64: /usr/lib/llvm-3.4/lib/libclang.so.1
libclang1-8: /usr/lib/llvm-8/lib/libclang.so.1
libclang1-3.5:amd64: /usr/lib/x86_64-linux-gnu/libclang.so.1
libclang1-3.8:amd64: /usr/lib/llvm-3.8/lib/libclang.so.1
libclang1-3.9:amd64: /usr/lib/llvm-3.9/lib/libclang.so.1
libclang1-3.5:amd64: /usr/lib/llvm-3.5/lib/libclang.so.1

/usr/lib/x86_64-linux-gnu/libclang.so.1 symlink points to 3.5

This code https://github.com/microsoft/ClangSharp/blob/dd684be635c90cb31e4c228e9896ca1fc7d47d7b/sources/ClangSharp/Interop.Extensions/clang.ResolveLibrary.cs#L13-L36

prevents me from changing that horrible behavior since static ctor will fail with TypeInitializationException if I try to set my own resolver.

[kekekeks]

Note that this logic effectively skips libclang installed from libclang.runtime.ubuntu.18.04-x64 nuget package rendering said package to be useless.

[tannergooding]

This resolves the libraries based on the default search paths for the system and so it will preference an exact match before trying to fallback to just libclang.

The NuGet restore cache is not part of the default search locations for native library resolution and so there is no attempt to search for the package there. Any attempt to manually use the NuGet restore cache would be dependent on knowing the correct RID resolution logic in relation to the host platform, which is effectively a non-starter.

The native library not being copied to the output on Linux (it is correctly copied on Windows and macOS) is due to a NuGet issue in that it only looks for something matching linux-x64 and so fails to resolve for the actual host RID (ubuntu.18.04-x64). The ClangSharp CI works around this by explicitly setting the RID before building.

Until NuGet provides the appropriate fix for copying the binaries to the output, you will need to do something to ensure the correct package can be resolved. Some options include:

• pass /p:OVERRIDE_RUNTIME_IDENTIFIER=ubuntu.18.04-x64 when building
• manually copy the native dependency to the output folder
• set LD_LIBRARY_PATH to include the relevant search directories
• hook into clang.ResolveLibrary so custom search logic can be done at runtime
• install clang 10 via apt (which should add a libclang-10 or libclang.so.10 to your path)
• etc

https://github.com/NuGet/Home/issues/10571 tracks the largest issue around native packages for NuGet and I'd recommend upvoting it

[tannergooding]

Closing this as the original issue was answered.

Newer versions of ClangSharp now validate the loaded version of libClang matches the expected version.