search

kcat / openal-soft

OpenAL Soft is a software implementation of the OpenAL 3D audio API.
Other
2.22k stars 536 forks source link

Eager detection and usage of sndio can be problematic on Linux #989

Closed alexrp closed 7 months ago

alexrp commented 7 months ago

https://github.com/kcat/openal-soft/blob/111397c71a5f1c2c88e05da9c84edfdba2e472a4/CMakeLists.txt#L994-L1006

On Linux, it seems not good to link directly to libsndio.so just because it happens to be present on the build machine. Most of OpenAL Soft's backends seem to use dynamic loading, but the sndio one doesn't, so the resulting libopenal.so will have a hard dependency on libsndio.so (and libbsd.so, libmd.so, ...).

Would it make sense to disable this backend by default? Or, if that's disruptive for BSD users (I don't know how important sndio is there), could we condition the eager usage of it on something like a !Linux check?

alexrp commented 7 months ago

Side note: The conflation of "sndio" and "SoundIO" terminology in the CMake files was quite confusing considering the existence of libsoundio...

kcat commented 7 months ago

I'm not sure how reliant BSD is on sndio these days, whether it's the primary way for apps to do audio or if they have better compatibility with more common APIs. In either case, having it disabled by default for non-BSD systems is probably the way to go since it isn't loaded dynamically.

Good point about sndio vs soundio. I'll look to making that more consistent as sndio.

alexrp commented 7 months ago

Sounds good. FWIW, I can send a patch for this if you like. :eyes:

kcat commented 7 months ago

This should be done now with commit 7dcfe0fe280cb1c66292fa0ed82ae50f17be8b08 (though you may need to use the latest commit 09cf896ad5d6b8b8b193fc86143567bc5d71b06a to fix a missing include error some systems may get).

alexrp commented 7 months ago

Thanks! I just tried a build with master and the dependencies now look to be what you'd expect:

❯ ldd libopenal.so
    linux-vdso.so.1 (0x00007ffe661e5000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000073a61f400000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000073a61f315000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000073a61f6dd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073a61f000000)
    /lib64/ld-linux-x86-64.so.2 (0x000073a61f8fe000)

vs previously:

❯ ldd libopenal.so
    linux-vdso.so.1 (0x00007ffce45c2000)
    libsndio.so.7 => /lib/x86_64-linux-gnu/libsndio.so.7 (0x00007def2bcbc000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007def2ba00000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007def2b915000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007def2bc98000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007def2b600000)
    /lib64/ld-linux-x86-64.so.2 (0x00007def2bed2000)
    libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007def2b80f000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007def2bc81000)
    libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007def2bc72000)
alexrp commented 7 months ago

Although libasound.so.2 not being a dependency now seems odd - is that an expected side effect?

alexrp commented 7 months ago

Ah, never mind - libsndio.so depends on it, so that seems expected indeed.