ClangSharpPInvokeGenerator fails on MacOS (Apple silicon)
The latest global tool (ClangSharpPInvokeGenerator v 13.0) installs fine, however when I run from the command line it cannot find libClang. Is there an extra installation of LLVM that needs to be done?
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.DllNotFoundException: Unable to load shared library 'libclang' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibclang, 0x0001): tried: 'liblibclang' (no such file), '/usr/local/lib/liblibclang' (no such file), '/usr/lib/liblibclang' (no such file), '/Users/jason/dev/elysium/cs/Elysium.Engine/liblibclang' (no such file), '/usr/local/lib/liblibclang' (no such file), '/usr/lib/liblibclang' (no such file)
at ClangSharp.Interop.clang.getClangVersion()
at ClangSharp.PInvokeGenerator..ctor(PInvokeGeneratorConfiguration config, Func`2 outputStreamFactory) in /_/sources/ClangSharp.PInvokeGenerator/PInvokeGenerator.cs:line 71
at ClangSharp.Program.Run(InvocationContext context) in /_/sources/ClangSharpPInvokeGenerator/Program.cs:line 559
Clang is installed as part of XCode:
$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
It looks like the clang installed with xcode isn't part of the default resolution paths for arbitrary tools.
You'd need to ensure it is resolvable either by adding the relevant path to the native library loading search paths or ensuring libclang is itself on one of the existing search paths.
@tannergooding could you elaborate on how to specify the native library path? I tried installing standalone LLVM, but it also gets installed to a location not compatible with these default search paths. I wonder if the default search paths need revision for MacOS platform?
Adding some context here for another MacOS/Apple Silicon user —
https://github.com/dotnet/ClangSharp/issues/46#issuecomment-1174461768 https://github.com/dotnet/ClangSharp/issues/351#issuecomment-1174451761
Also getting DLL missing issues.
I wonder if the default search paths need revision for MacOS platform?
.NET simply uses the system default resolution path for a given platform. If .NET can't resolve it then a standard native executable wouldn't resolve it either.
Copying the native libraries next to the executable will "typically" allow resolution to succeed. As would ensuring they are in one of the folders on the default search path for the system. You may have to use tools or environment variables (i.e. LD_DEBUG environment variable or the ldd tool on Linux, unsure of the correct one for MacOS) to help diagnose resolution failures otherwise.
I'm placing libclang in all the places the DLL is reporting as looking but the program seems not to resolve any of the paths as correct. Can you look at my other linked issues and see if it even looks right?
You need both libClangSharp and libclang to be resolvable. Its reporting to fail to find the latter.
Sorry - that one picture was slightly out of date. See the other comment:
I've tried symlinking in to Clang on the system via xcode's path and the usr/bin/ clang version to no avail. Not totally sure what's missing here, would love any additional help. Also weird that it's looking for liblibclang and not just libclang, but idk if that's relevant.
What I'm wondering is that since it's an M1 it's looking for an M1 compiled clang or clangSharp?
It might be and there is no corresponding version of libClangSharp for Apple M1 today. I'd expect if you ran it under x64 mode it would work however.
Notably, the picture I saw showed a symlink to clang, not libClang, them being two different binaries. You might try just copying libClang itself next to the executable. You can also get the pre-built binary from https://www.nuget.org/packages/libclang.runtime.osx-x64 if nowhere else.
Ah, I wasn't aware they were different. I'll give that a go and see what happens
I'm publishing osx-arm64 binaries as part of v15.0.0 (going to track via https://github.com/dotnet/ClangSharp/issues/345).
Just updating this as well for anyone that finds themselves here as I finally got around to fixing this and there's been some updates.
You can manually download the libclangand libclangsharp binaries for Apple M1 from the nuget packages here:
libClang: https://www.nuget.org/packages/libclang.runtime.osx-arm64 libClangSharp: https://www.nuget.org/packages/libClangSharp.runtime.osx-arm64
If installed as a Global dotnet tool, you can just put the .dylib files next to your install of ClangSharpPinvokeGenerator here (or your version):
/Users/kyle/.dotnet/tools/.store/clangsharppinvokegenerator/16.0.0/clangsharppinvokegenerator/16.0.0/tools/net7.0/any
I was able to get the tool to work this way.