search

sjoerdvankreel / xt-audio

Platform independent low-latency audio for C, C++, Java and .NET.
https://sjoerdvankreel.github.io/xt-audio/
Other
64 stars 12 forks source link

Cannot be used after compiling in centos9 #25

Closed fanshuxian closed 6 months ago

fanshuxian commented 8 months ago

System version : Centos 9 gcc version : 11.4.1 cmake version : 3.26 Build cmd : sudo ./build.sh x64 ON ON OFF

Then to Xt.Sample.csproj project path excute "dotnet build Xt.Sample.csproj" (project update to .net6.0), excute "sudo dotnet ./PlayAudioFile.dll" get Exception: Unhandled exception. System.TypeInitializationException: The type initializer for 'Xt.XtAudio' threw an exception. ---> System.DllNotFoundException: 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

image

How to fix this error, Looking forward to your reply. Thanks.

sjoerdvankreel commented 8 months ago

I'm getting the exact same results on ubuntu 22. I've narrowed it down to this: https://github.com/actions/runner-images/issues/6029. Relevant link over there is this: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html.

Quote:

"In order to support smoother in-place-upgrades and to simplify the implementation of the runtime all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc. New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility, empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are provided, so that the linker options keep working. Applications which have been linked against glibc 2.33 or earlier continue to load the corresponding shared objects (which are now empty)".

And indeed, if you change the xtaudio source code over here https://github.com/sjoerdvankreel/xt-audio/blob/master/src/net/xt/XtAudio.cs from [DllImport("libdl.so")] to [DllImport("libc")], things start working again. I also guess the comment "Applications which have been linked against glibc 2.33 or earlier continue to load the corresponding shared objects" means that the nuget version of xt-audio is still fine.

It seems like nobody thought about source-code compatibility for stuff that dynamically loads libdl? Not sure about this, I'm not much of a Linux programmer.

What would be the best course of action here? Can you think of any way to modify the source code to work with both libc <= 2.33 and libc >= 2.34? Or maybe i should just ditch <= 2.33 and go with the new one. Publish new binaries, new nuget, new maven and all that. Not sure yet.

-cheers, Sjoerd

ofsjoerdk commented 6 months ago

Decided to just get with the program and go for libc. 2.34 is almost 3 years old already so i don't expect much problems with this.