Fix shared object name for loading libdecor

[kya8]

Description

Fix runtime loading of libdecor by using the proper soname instead of the linker name, which is absent on some systems.

Related Issues

Fixes #18540

[hizzlekizzle]

Will changing that bool break it on systems where it already works? Should it be switched to an OR (||) check instead of replacing?

[kya8]

Will changing that bool break it on systems where it already works? Should it be switched to an OR (||) check instead of replacing?

libdecor-0.so is only used at link time, so it shouldn't be depended upon at runtime. Usually it's a symlink to the versioned soname, but it can be a linker script too.

On systems where libdecor-devel is installed, or systems that does not split packages (e.g. Arch Linux, Gentoo, etc.), or when the user compiles and installs libdecor by themselves, libdecor-0.so.0 is also guaranteed to exist.

But the reverse is not true. RetroArch packaged by Linux distros that do split packages will not (and should not) depend on libdecor-devel as a runtime dependency, i.e. only libdecor-0.so.0 and libdecor-0.so.0.200.5 are present. Hence the bug I've reported. It already breaks wayland CSD on common Linux distros.

I'm not aware of systems (where libdecor is suported) that use the name libdecor-0.so for the actual shared object, at least for Linux and BSDs.

[kya8]

If we want extra robustness in the unlikely situation where libdecor-0.so exists as the shared object but libdecor-0.so.0 is absent, we could try loading the versioned name first, and load the unversioned name if that fails:

if ((wl->libdecor = dylib_load("libdecor-0.so.0") || dylib_load("libdecor-0.so")))

But I don't think this is necessary.

[hizzlekizzle]

I'll check my system at home. It's possible I made a symlink a long time ago and forgot about it.

EDIT: looks like I have both, so I probably symlinked it at some point to fix exactly this. We can probably safely disregard my initial concern.