DLL Not Found on Ubuntu (libClang is installed)

[GideonUng]

libClang is installed. both in version 14 and 15

gidcheen@Laptop:~$ ClangSharpPInvokeGenerator --version
ClangSharp P/Invoke Binding Generator version 15.0.0
Ubuntu clang version 15.0.6
Failed to resolve libClang or libClangSharp.
If you are running as a dotnet tool, you may need to manually copy the appropriate DLLs from NuGet due to limitations in the dotnet tool support.
Unhandled exception: System.DllNotFoundException: Unable to load shared library 'libClangSharp' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibClangSharp: cannot open shared object file: No such file or directory
at ClangSharp.Interop.clangsharp.getVersion()
at ClangSharp.Program.Run(InvocationContext context) in /_/sources/ClangSharpPInvokeGenerator/Program.cs:line 269
at System.CommandLine.Handler.<>c__DisplayClass1_0`1.b__0(InvocationContext context)
at System.CommandLine.Invocation.AnonymousCommandHandler.<>c__DisplayClass2_0.<.ctor>g__Handle|0(InvocationContext context)
at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext context)
at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass18_0.<b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass13_0.<b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass20_0.<b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__19_0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<b__6_0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass9_0.<b__0>d.MoveNext()

[tannergooding]

As covered in your other issue #422 (comment)

The error message explicitly states what's going on and provides a suggestion on how to resolve this

Specifically, it states:

1. "Failed to resolve libClang or libClangSharp."
2. "If you are running as a dotnet tool, you may need to manually copy the appropriate DLLs from NuGet due to limitations in the dotnet tool support."
3. "Unable to load shared library 'libClangSharp' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibClangSharp: cannot open shared object file: No such file or directory"

This tells you, respectively:

1. There are two possible dependencies that may have failed
2. The most common source of the failure and how to fix it
3. Exactly which of the two dependencies caused this specific failure and suggests a way to get more diagnostic information

If there is a way to make this clearer, then suggestions and contributions are welcome. However, as is the error information does state all the required information, particularly when taken in coordination with the repo's README which gives explicit links to the relevant NuGet packages by name.

[GideonUng]

Im sorry but this is a stack trace. Your question of can it be made clearer is a quite obvious yes.

1. that should not happen after following the documented installation instructions
2. Copying dlls from some nuget is not a valid path to fix this on the user side. Its wild to me that trial and error copying of dlls to places is viewed as an appropriate step to resolve this.
3. Im not debugging issues on the applications side as a installation step. maybe to file a bug report but this cant be an expected user experience.

[tannergooding]

Im sorry but this is a stack trace

Only part of the output is a stack trace. The first 5 lines are regular tool output that exist specifically to surface the error, call out the most common source of the failure, and to list the possible fix.

The remaining lines are the stack trace which exists for diagnostic purposes. As a developer oriented and open source tool, listing the stack trace ensures that people can further diagnose the issue on their own if necessary and/or provide additional information to the maintainers if its something that they need assistance with.

A stack trace existing, particularly in a developer oriented tool, shouldn't be a reason for a user to completely ignore the output.

that should not happen after following the documented installation instructions

The issue here is on the end of the general dotnet tool support and there being a lack of functionality. There is not really anything that ClangSharp can do to improve this experience given that a NuGet package cannot be correctly packaged to provide only the required binaries for a given platform and that providing everything in a single package is untenable due to the package size being over the NuGet upload limits and unpacking to something that is over a gigabyte in size.

Notably the README could additionally call out the same note that the command line already does. Which is that on some platforms you may need to explicitly copy libClang and/or libClangSharp to a path where they can be resolved and to likewise refer to NuGet as a place where such binaries can be retrieved. PRs are welcome ;)

Copying dlls from some nuget is not a valid path to fix this on the user side. Its wild to me that trial and error copying of dlls to places is viewed as an appropriate step to resolve this.

There is no trial and error. It tells you exactly which dependency you need and which major version you need.

If you're on Ubuntu 20.04 you use https://www.nuget.org/packages/libClangSharp.runtime.ubuntu.20.04-x64. If you're on 22.04, you use https://www.nuget.org/packages/libClangSharp.runtime.ubuntu.22.04-x64

If you're on MacOS Arm64: https://www.nuget.org/packages/libClangSharp.runtime.osx-arm64

etc.

Im not debugging issues on the applications side as a installation step. maybe to file a bug report but this cant be an expected user experience.

You will see similar with many Linux based tools that aren't installed via the distro specific package manager and even then you may see some there as well due to conflicting dependencies or other issues.

An application should not go and download files from the internet itself without explicit user action. It could offer to do so, and require the user to consent via the command line, but many users have indicated that is a "worse experience" in the past and that they would prefer to explicitly control what native binaries are available on their box.

While it is indeed not ideal that the dependencies cannot be implicitly provided SxS, it is not entirely an application side issue. It is just as much a machine configuration issue due to it missing a required dependency.

It is not perfect and the process of interoperating between two languages, let alone parsing one language and generating compatible bindings for another, is incredibly error prone and complex. Using such a tool requires some level of effort on the consumer to minimally understand both C/C++ and C#, and to provide the necessary information for the tool to run correctly and generate the relevant bindings.

There is no magic "easy" button that will do it for you, because no two C headers work the same way. Resolving native dependencies, especially when very explicit instructions are given, should not be considered an insurmountable task.

[tannergooding]

This is an open source tool is being maintained by an single developer, in their free time. They do not get paid to work on it, it is not being sponsored by any companies, etc.

As such a free and open source tool, contributions are more than welcome to improve the experience as are suggestions if you find something lacking. However, such contributions and/or suggestions must be made in good faith and in a constructive manner.

Making statements along the lines of "this isn't good enough" is not constructive.

Opting to not read the console output that states the error and gives a possible solution is not constructive.

Not listening to maintainer guidance when the issue is explained in more detail including why it is the way it is today, particularly when they have explicitly stated that it is indeed non-ideal but that they don't have a good solution, is not constructive.

[tannergooding]

Command line output has been updated to make the callout on missing dependency more visible and to link to the GitHub repo.

README has been updated to further callout and elaborate on the dependency resolution issue and how users can pick the right package