delamesa: It's a pity this issue is already solved, I was just getting comfortable to learn some neat tricks.
Hey, that's what we're here for, right? ;)
delamesa: Can I do anything for you?
Just keep learning and help others!
delamesa: To explain how it works... Running ldd on the game now shows that all libs are indeed pulled from /usr/lib32 and now there are even some new ones listed... As if alternatives to the ones inside the i386 folder were specified in case they were missing.
Ok, so this is a big topic and I'm not trying to run down a technical rabbit hole here in the GOG forums, but I'll try to give you a cursory explanation.
When you're building an application, some libraries are "statically" linked—i.e. they're included in the final binary—while others are "dynamically" linked, meaning they are expected to be provided by the system, and they'll be loaded when they're needed. This avoids the huge waste of space that would come from every program having its own copy of, for example, libm (the C math library). Dynamically linked libraries are also often referred to as "shared" libraries.
There are a number of tools you can use to look for these external library dependencies. In this case you were using
ldd, which typically just runs the standard dynamic linker (
ld) against the binary with an option to retrieve the shared libs the binary requires.
To Answer Your Question: ldd acts recursively, listing not only the direct library dependencies, but also the shared libraries on which they depend. So those new listings you see have been dynamically linked against by one or more of the pre-existing dependencies.
Some other common tools for these sorts of tasks are
readelf, which displays various info about ELF (Executable and Linkable Format) binaries common to Unix and Linux systems, and
nm, which can be used to read symbols more directly (you probably don't ever need
nm).
So if you wanted to see direct dependencies, you could probably do something like "
readelf -d /path/to/VictorVranGOG" to display a human-readable version of the binary's "dynamic" symbols section.
I'm on a Mac at the moment, so I can't run any of this myself to test, but hopefully you get the gist of it.
There are some special kernel libraries that must exist for the system to function but won't list with an arrow (=>) in
ldd because they're not looked up the same way—like
vdso (the Virtual Dynamic Shared Object library), which allows the kernel to provide commonly used low-level user-space functionality, or
ld-linux, which is the (usual) ELF interpreter library itself. So if you're using
ldd and you see a lib without an arrow, it's
possible that it's not actually missing, so your mileage may vary :)
Back To Your Question: When dynamic libraries are provided along with an application, they sometimes conflict with what the system already has. So, for example, GOG officially supports Ubuntu, meaning that they expect developers to provide Linux games that will run on a relatively up-to-date version of Ubuntu... but you're not on Ubuntu. So the libraries they provided might depend on other libraries that would probably be present on a recent version of Ubuntu, but Solus might be missing them or have a newer "major" version (according to SEMVER notation) that uses an updated (i.e. incompatible) API.
So a lot of the time, the easiest way to troubleshoot a dynamic library issue is to scrap the provided libraries entirely, run
ldd to see what's available and what's not, and then either install a matching version or start copying the missing libs back in one at a time.
I think that's all I've got without getting
way too technical, so I hope that clears things up a bit for you.
Have fun and help others :)