Closed mcdee closed 1 year ago
Thanks for reporting @mcdee, we have seen this issue with our users too... It seems like upstream you had a solution here, did that fix the problem? I could incorporate something like that directly here if necessary.
I'm afraid that I'm not able to comment on the solution here as I haven't seen it in operation. I think an alternative was to wrap the load such that if it threw an exception then it could be caught and another attempt to load from a different DLL (libc) could be attempted, but I'm not sure of the relative merits of the two approaches.
@mcdee let's see, I added some special handling for the loader to try to load the alternative name in case it fails. Feels hacky, but if it works we can close this issue for now.
For future reference, it seems like we can import the same methods but from the libcoreclr.so library, that is provided by the dotnet runtime and sits next to the library, as seen here:
https://gitlab.com/josetruyol/faisssharp/-/blob/master/FaissSharp/Internal/UnmanagedLibrary.cs
Which means this dependency on libdl might be completely unnecessary
@mcdee let's see, I added some special handling for the loader to try to load the alternative name in case it fails. Feels hacky, but if it works we can close this issue for now.
fwiw; I was facing this issue and after upgrading from 7.4.x to 7.5.x it's working again. Thanks !
There are various
DllImport("libdl")
directives in this repository, however versions of glibc since 2.3.4 have removed libdl as a shared object (i.e. they no longer provide alibdl.so
), which causes this to fail to load.Notes from glibc 2.3.4: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html