Running the Linux game version on Solus via Lutris. Installation went fine as far as I can tell.
After launch, a starting/background screen of Victor Vran appears for 1 second, then the game closes with the following error:

Running Victor Vran
Protocol error: bad 3 (Window); Sequence Number 5
Opcode (20, 0) = GetProperty
Bad resource 1483866712 (0x58720258)
at -e line 15.
support/gog_com.shlib: line 94: 22227 Segmentation fault ./"${bin_64}"

tried:
-disable lutris runtime
-prefer system libraries
-add (alternating) /usr/lib32 and /usr/lib64 to LD_LIBRARY_PATH

result:
error stays the same for all tries.

Any way to get the game to run?

edit:
I've tried the GOG installer having set chmod +x to the shell script. Installation went fine. Started the game via ./start.sh
The error pattern (closing 1 second after launch) stays the same though.

how to delete this post?

If you've solved the issue, it might be helpful to post your solution for other users.
Alternately, if you found a solution in another thread, you could link/reference that here.

I wanted to delete the double post, not the whole issue, which still persists for the Linux version. I have simply missed the edit button.

I've downloaded the windows version now and got it to run successfully via wine/dxvk. There is no sound when using wine 4.1, but the protonified version of wine 4.1 seems to have fixed an issue with xAudio2 (a windows api), which caused the missing sound.

The game runs fine, no problems so far, stable fps, I'm Level 12. :)

oic ;) Glad to hear you got it working (even if a separate download and wine was required).

As to the base issue—did you try running the game binary directly (i.e. ./VictorVranGOG) instead of using start.sh? The start script is there to load the distributed libs instead of your system ones... which doesn't always work out.

As I recall, VV for linux only comes with a 32-bit binary, so you'll probably want to stick with the 32-bit libs.

Try running the game binary directly. If you get errors, give it another go with LD_LIBRARY_PATH=/usr/lib32. If it's still a no-go, run ldd ./VictorVranGOG to get a list of the required libs to see if you're missing any.

I'm more of a Debian/RedHat guy, so I'm not super familiar with Solus's PiSi/eopkg package installation—but on Ubuntu it'd be something like sudo dpkg --add-architecture i386 to get the basic 32-bit packages installed. Basically you want to start with the 32-bit essentials like libasound2, libstdc++, libgcc, etc.

1. Tried both, the start.sh and after you mentioned it the binary VictorVranGOG in the /game subfolder. Same error: game closes promptly after showing the castle background. Lutris' log:
Running Victor Vran
Protocol error: bad 3 (Window); Sequence Number 5
Opcode (20, 0) = GetProperty
Bad resource 1483866712 (0x58720258)
at -e line 15.

2. Not sure how to tell whether or not a library is actually missing. The list is about 50 entries long. No line shows as "missing" or "library not loaded" or anything like that. The hex value indicates where in the memory the library is loaded and the => symbol where the used library is loaded from. Most of the ones listed are from the game's i386 subfolder and only a handful are pulled from /usr/lib32, those are:
libpthread.so.0
libdl.so.2
libm.so.6
libgcc_s.so.1
libc.so.6
/lib/ld-linux.so.2
librt.so.1
libresolv.so.2

Only the first one in the list (linux-gate.so.1) doesn't have a => symbol next to it, but a hex value like all the others.

3. As for Solus and package management: usually everything that is needed is available in the repo. I'd assume library essentials would be in /usr/lib32 already, but a preliminary search for libasound2 hasn't brought up any location in root. I'll get into that.

But how to tell what libraries are actually missing? When I do a ldd /usr/bin/firefox the list looks similar to the others from VV, no errors or lines that look totally different, everything is loaded into memory it seems.

Thanks for your reply btw.
I hope we can continue sorting the problem, I'm actually learning. :)

(Skipping 1)

2. Get very comfortable with piping grep and sed for filtering and contextual replacement. Until then, Linux is going to be rough.

3. Terrible assumption! But no reason to hold that against you—like ya said, you're learning ;)

With most distros, the only libs pre-installed are those required to run the base pre-packaged software. Any additionals are a waste of space. It's assumed that anything you install through your package manager will list (and therefore install) the required dependencies when they're needed.

A quick search brought up that a lot of people get their base 32-bit libs on Solus by installing Steam, as it depends on most of the 32-bit libs, and then removing Steam. So that's worth a try if all else fails.

If you're willing to do it manually, though, try "eopkg search 32bit" and then compare the list to your ldd output. Apparently all the 32-bit lib packages in Solus end with "-32bit", so it's an easy filter. You can grep the ldd list with a simple bash loop to look for matches (if they named the eopkg lib packages correctly), but you might need to mangle 'em with sed to drop the version numbers.

Yes, I'm leaving the command specifics as a learning exercise. Read your man pages :)

This is the differential list, with some notes:

---Missing
libpth-32bit is installed -- same as libpthread?
libdl
libcurl-gnutls
libopenal
libSDL2-2.0
libm
libgcc is installed -- same as libgcc_s?
libc
/lib/ld-linux
liblber-2.4
libldap_r-2.4
librt
libgssapi_krb5
libz
librtmp
libresolv
libsasl2
libgssapi
libkrb5.so.3 -- neither is available, how do they differ
libkrb5.so.26 -- are both included in libkrb5?
libk5crypto
libcom_err
libkrb5support
libuuid
libheimntlm
libasn1
libhcrypto
libroken
libkeyutils
libwind
libheimbase
libhx509
libsqlite3

The list in post no. 6 is way shorter for those that are pulled from /usr/lib32. How is it that not only those libaries are missing as all the others are in the game's subfolder i386 and thus available from the game itself? Just to get the problem straight.

Aaaand strike! Moving the i386 folder out of the game directory was just the curveball we needed. :)

It's a pity this issue is already solved, I was just getting comfortable to learn some neat tricks.
Can I do anything for you? I'll at least vote all your posts up ofc, very hands down and outright helpful, each one of them.
Thanks a lot!

To explain how it works: if the game pulls many of those unusual but needed libraries from the game/i386 folder, why does it work even when those libs are out of sight? 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, like:
libnettle
libhogweed
libunistring

As if alternatives to the ones inside the i386 folder were specified in case they were missing. Help me understand this, please. :)

Hey, that's what we're here for, right? ;)

Just keep learning and help others!

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 :)

I wanted to inquire some more, but I feel the topic is best left solved and not derailed further. But it's those rabbit holes that provide insight most of the time though, so it's hard to resist. And thanks again for shedding light on this library topic. :)

Have a bliss day!

No problem at all!

When someone wants to learn and troubleshoot it's a refreshing change from the more common "It's broken! The devs suck!" They do the best they can and 100% system coverage just isn't realistic. The way I see it, if they're willing to put their software out there DRM-free and at reasonable prices, it's the least we can do to help the community access it.

Hopefully every conversation like this helps a few people out there, so thanks for sticking with it!

Take care :)

For a lot of people that issue was due to only having the the 64-bit OpenGL libraries installed, and simply required grabbing the 32-bit version (i386) from the repo -- which is mentioned in the game listing.

Others were running open source video drivers that didn't support later OpenGL versions. Solution there was usually to switch to proprietary drivers or upgrade the open source drivers via a PPA.

Then there were the library dependency conflicts (like in this thread) where the solution is simply deleting the conflicting files.

That's what the forums are for ;)

I don't know about that.

There are plenty of problems for Windows users where games won't work between Windows versions, with certain video drivers, or without setting a compatibility mode or running as administrator.

Usually someone asks you to generate a system report, which is unintelligible to most users. Then they suggest something like editing the registry, which is far more tedious and potentially destructive than what Linux users generally go through in a terminal.

Other times it's simply missing drivers or DLLs. But getting those files for Windows users means heading over to their favorite search engine to scour a myriad of disparate file hosts and then downloading missing files from an unknown or untrusted source. A unified package repository system is significantly easier to me.

For gaming on Linux, the "easy" mode is sticking to Ubuntu -- just like sticking to a recent version of Windows. It's bloated and gives you less control then you'd like, but it just works most of the time, and usually your problems can be solved without ever opening a terminal.