liblibdl.so not found

[Christopher Pons]

I just upgraded to Pop OS 21.10, from 20.04 and I started getting this exception when trying to load a model. It looks like there’s an appended “lib” which causes the lookup to fail. As a terrible workaround I copied libdl.so.2 as liblibdl.so in my /usr/lib/x86_64-linux-gnu folder. A proper fix would be appreciated.

An unhandled exception of type 'System.DllNotFoundException' occurred in AssimpNet.dll: 'Unable to load shared library 'libdl.so' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibdl.so: cannot open shared object file: No such file or directory'
   at Assimp.Unmanaged.UnmanagedLibrary.UnmanagedLinuxLibraryImplementation.dlopen(String fileName, Int32 flags)
   at Assimp.Unmanaged.UnmanagedLibrary.UnmanagedLinuxLibraryImplementation.NativeLoadLibrary(String path)
   at Assimp.Unmanaged.UnmanagedLibrary.UnmanagedLibraryImplementation.LoadLibrary(String path)
   at Assimp.Unmanaged.UnmanagedLibrary.LoadLibrary(String libPath)
   at Assimp.Unmanaged.UnmanagedLibrary.LoadLibrary()
   at Assimp.Unmanaged.UnmanagedLibrary.LoadIfNotLoaded()
   at Assimp.Unmanaged.AssimpLibrary.CreatePropertyStore()
   at Assimp.AssimpContext.CreateConfigs()
   at Assimp.AssimpContext.PrepareImport()
   at Assimp.AssimpContext.ImportFile(String file, PostProcessSteps postProcessFlags)
   ...

‌

[NoTuxNoBux]

I’m experiencing the same issue after trying AssimpNet again after a while on Linux.

I think the problem is that libdl.so no longer exists: it has been merged in libc itself. This means the fix could be as simple as changing [DllImport("libdl.so")] to [DllImport("libc.so")], but that will break Linux platforms with older glibc versions. Some sort of fallback would need to be put in place.

[Nicholas Woodfield]

Are either of you on the new .NET 5+ versions? I’ve been thinking about revisiting AssimpNet and leaving a lot of the legacy stuff behind, modernize it for the newer APIs, Spans, NativeLibrary, etc

[NoTuxNoBux]

Thanks for the response.

In my case, the answer is “it’s complicated”, because whilst I use the latest .NET versions (6 even) as much as possible, and am eager to do so, I’m also developing for Unity most of the time, and it only just moved to .NET Standard 2.1 with Unity 2021.3 LTS (they’re lagging behind quite a bit), where .NET 5 projects are not supported yet.

I do have some other good news, though, the company I work for uses Assimp in Unity, and I’ve been working on updating the platform support a bit. I already fixed this issue, am looking into merging the UWP support I already did in #73 somewhat cleanly into that, and might also take a whack at Android support. I’m hoping to send a PR soonish - even if it doesn’t get merged as a whole immediately, it might help others to get started.

[NoTuxNoBux]

I upstreamed the promised changes in PR #5, which include a fix for this by trying libc.so.6 first and falling back to libdl.so for older systems. (Android support is not in yet, though, I have to do further tests for that.)

[bluesillybeard2 bczhefgthspswd]

I am having this issue as well - I am trying to find a workaround, but AssimpNet is a little too complex for me to figure out.
Ideally it wouldn’t need anything beyond what .NET has, but I see why external libraries are required.
I am using .NET 7.0 on Manjaro XFCE in case you were wondering.

[bluesillybeard2 bczhefgthspswd]

I got around it by cloning the source code and directly referencing the .csproj file, so I have a version from after it was fixed.

By the way, shouldn’t this issue be closed? Or is it waiting until the fix is released on Nuget?

‌

[Nikola Berdić]

Is it possible to get a new nuget package of the most recent version? I’m experiencing the same issue.