@dotnet-policy-service agree

Hello @Pixelstormer, this is failing the macOS build, I guess we need to either ifdef or do the lookup at runtime.

Can you look into it?

So, the problem is that on macOS, libraries use the .dylib or .bundle extensions, and not the .so extension like on Linux. Unfortunately, DllImport has no way of specifying multiple possible library names, and the recommended workaround of NativeLibrary.SetDllImportResolver isn't available on netstandard. I've pushed a fix that just chooses between Linux and macOS versions of the functions, similarly to how it was already choosing between Unix and Windows versions. This isn't the nicest fix, given that the functions are completely identical besides the name of the library they're imported from, but it does work.

On an unrelated note, I noticed that the PlatformID enum that was being used to distinguish between platforms apparently shouldn't be used any more, as amongst other things, it can't actually distinguish between macOS and Linux, instead grouping them both together as Unix. To solve this, I replaced it with the recommended alternative of OSPlatform. There's several other places in the codebase that also use PlatformID, but changing those are out of the scope of this PR.

Cool, that makes sense. Thanks for the contribution.