Load PulseAudio/ALSA dynamically (dlopen) on Linux / *BSD

[akien-mga]

Godot version:
Current master (51a0a38), but could be backported to other stable branches.

OS/device including version:
"X11" platform / any freedesktop.org OS (Linux distros, OpenBSD, FreeBSD).

Issue description:
For the X11 platform, we currently link the PulseAudio library (libpulse.so.0, libpulsecommon-10.0.so) directly in official binaries, which means that our binaries can't be used on systems without PulseAudio (especially relevant for Arch or Gentoo users, as well as any user with a strong aversion for PulseAudio or any Poettering endeavour).

This means that to support such users, game developers need to provide a Linux binary compiled with pulseaudio=no, which causes a fallback to ALSA (libasound.so.2).

[akien@cauldron godot.git (master)]$ ldd ~/tmp/godot/stable/Godot_v3.0.6-stable_x11.64 | grep pulse
        libpulse.so.0 => /lib64/libpulse.so.0 (0x00007f345cdf1000)
        libpulsecommon-10.0.so => /usr/lib64/pulseaudio/libpulsecommon-10.0.so (0x00007f345b6bf000)
[akien@cauldron godot.git (master)]$ ldd ~/tmp/godot/stable/Godot_v3.0.6-stable_x11.64 | grep asound
        libasound.so.2 => /lib64/libasound.so.2 (0x00007fbe43c9f000)

It would be better if we loaded these shared libraries dynamically with dlopen() instead of linking them upfront, allowing to run Godot even if they are missing (eventually defaulting to the Dummy audio driver if both are missing).

[crabctrl]

This still appears to be a problem with the latest release

[alanswanson]

The #22604 implementing dlsym loading for libpulse.so.0 appears to have been closed (not merged) without the alternative solution being discussed by @hpvb ever being implemented.

While projects distributed on steam will run using its runtime, projects distributed on gog or itch will fail without libpulse.so.0 (if the library is not included and rpath origin for binary set in the linker).

[sylware]

I ran into this issue.

But the bottom of this: godot should only be a glibc ELF binary and:

• the init code should dynamically load all required libs. Such binary should discover the core video games libs: x11 libs/wayland compositor, vulkan/GL, alsa/libpulse. For third party libs, don't expect a distro to have them: all distros are not the size of the huge mainstream ones, they should be distributed with the games.

[Calinou]

I think there are plans to dynamically load X11/Wayland libraries as well, so that a single binary can be used both on a desktop and a headless server (which doesn't have an active display server Godot can connect to).

For third party libs, don't expect a distro to have them: all distros are not the size of the huge mainstream ones, they should be distributed with the games.

Libraries are already statically linked into the binary, unless this is not possible or ill-advised (such as for glibc itself).

[crabctrl]

Libraries are already statically linked into the binary, unless this is not possible or ill-advised (such as for glibc itself).

I would just like to comment that although this is great for the official binaries, providing an easy option for configuring the build script to NOT use statically linked or bundled libraries is essential, as not doing so makes life very difficult for package maintainers...

I've seen quite a few projects that not only don't provide an easy option to disable it, but actually depend on bundled libraries for their software to work, which makes the software impossible to properly package on systems which depend on custom-compiled libraries, such as Gentoo.

[Calinou]

I would just like to comment that although this is great for the official binaries, providing an easy option for configuring the build script to NOT use statically linked or bundled libraries is essential, as not doing so makes life very difficult for package maintainers...

This is already available, and has been the case for a long time 🙂

Check the builtin_* SCons options using scons -h.

Also, Godot is already packaged in many Linux distributions.

[ghost]

Libraries are already statically linked into the binary, unless this is not possible or ill-advised (such as for glibc itself).

How about statically linking to musl libc to allow exporting for all distros at once?

[Calinou]

How about statically linking to musl libc to allow exporting for all distros at once?

Applications that use OpenGL can't link against musl libc, because the system's libGL is typically linked against glibc. In the NVIDIA proprietary driver's case, this is something no distribution packager can fix 🙂

Headless/server binaries could link against musl, but this can cause subtle behavior differences (such as in string formatting or floating-point handling) that can result in difficult-to-track bugs.

[ghost]

Applications that use OpenGL can't link against musl libc, because the system's libGL is typically linked against glibc. In the NVIDIA proprietary driver's case, this is something no distribution packager can fix slightly_smiling_face

but what if you dlopen() libGL? also nowadays linux distros ship libGL as either mesa (because they don't ship nvidia in the first place) or glvnd (gl vendor-neutral dispatch library, created and maintained by nvidia)

gcompat can run glibc binaries on musl without installing shared libraries linked against glibc, so I think it's worth trying dlopen()'ing glibc-linked libGL with musl-linked program

Headless/server binaries could link against musl, but this can cause subtle behavior differences (such as in string formatting or floating-point handling) that can result in difficult-to-track bugs.

you remind me about this article (you'll have much fun if you read it) https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html 😄

you can read about behavior differences here https://wiki.musl-libc.org/functional-differences-from-glibc.html