I have noticed Pier Solar does not show up when typing 'linux' into the search above my library.

Sorry if this has been covered before in this thread (I have not read the entire thread), but is there any chance of GOG distributing Linux games in statically compiled form so that users who won't use Debian or one of it's derivates can install and run games without having to A) Install a 2nd distro and dual boot, B) try and find the (awkwardly named) libs that Debian et al use and install them locally (and find all of their deps), C) Try to install aforementioned distro in a chroot and have to fight with that install, or D) try installing another distro (and maintain it) in a VM?

As it stands, it took me 5 minutes to get Mount and Blade: Warband running in wine whereas trying to get it working natively resulted in me giving up 2 hours in trying to find and install the weird libs that were being asked for.

It's not up to GOG. They just distribute what the developers give them.

Now, on the other hand, bundling the libraries with the game like the better Humble Bundle Linux releases do... that's something you could ask for.

I have made a few packages that provide libraries without requiring you to go on a dependancy hunt, extract in main game folder and you're done.

Unreal Tournament 2004: http://www.gog.com/forum/unreal_series/unreal_tournament_2004_easy_setup_for_linux

Mount & Blade Warband: http://www.gog.com/forum/mount_blade_series/mount_blade_warband_linux_mint_easy_setup

The Witcher 2: https://docs.google.com/file/d/0Bw5Xv02Yq2HrbEZWVkZZSVpzV2s/


I've tested these on both Ubuntu and Linux Mint and they work out of the box, other distros may require additional dependancies however.

I thought that was the case, but one can hope. As soon as devs learn about the wonder of static linking, installing games in Linux will become so much simpler (and the distro restrictions disappear). Wouldn't that also require a small shell script to change an enviroment variable to search a relative path before searching the system?
Do you know of a (sane) way to find these libs for distros other than Ubunutu and Mint? A short guide on finding these dependencies and installing them somewhere restricted so a user could run these packages on another distro would be terribly useful.

I'd dig into it, but my last attempts at mucking about with .debs wasn't a happy moment and after my attempt at getting M&B:W I have little desire to dive into fixing something else game-related right now.

Static linking makes it quite painful to support games in the long term and on quirky niche distros. Often, the solution to some bug that's cropped up outside the developers' test context is to replace one of the bundled libraries with a different version or delete it so the system version takes over.

In fact, it's a big enough issue that SDL 2.x wraps all of its public API functions in a layer of indirection so that, by setting the SDL_DYNAMIC_API environment variable, you can ask a statically-linked copy of SDL to step aside and hand off to an external, dynamic copy of SDL.

You already need that for hybrid 32/64-bit packages (simpler and avoids the need to host two copies of the game resources, which are the largest part) and it's the simplest way to make relative library and resource paths work robustly using the same mechanism.

(You'd be surprised how many games I've seen that can't be easily run from the terminal and don't launch from GUI either because their only path fixup is the Path= key in the .desktop file and something like LXPanel ignored it.)

I think you misunderstand what static linking is. To statically "link" a program one includes a copy of the library in the binary. It entirely eliminates the need to call arbitrary system libs. The only exception that I am aware of are calls to the kernel, and given that the linux kernel attempts to maintain a stable ABI/API, that shouldn't be an issue.

Does this answer your question? http://pkgs.org/ :-)

This site makes downloading packages easily, also provides which dependencies they have and the packages themselves are taken from their respective distro's official repository.

I personally prefer it over the package manager as I feel I have much more control over my packages.

No, I'm quite aware what static linking is and do have some experience with C and C++. (Though I primarily work in languages like Python and JavaScript)

I'm talking about situations like:

1. When Waking Mars was released in one of the Humble Bundles, a lot of people had trouble with the game locking up on Linux. The solution listed on their support page is to replace the bundled copy of OpenAL. That would have been impossible if it were part of the game binary.

2. I'm forgetting their names, but I've fixed one or two games by deleting a bundled library so the system copy was used.

3. Historically, many problems have been fixed using LD_PRELOAD hacks (eg. the aoss and padsp audio compatibility shims) and LD_PRELOAD only affects functions resolved by the dynamic linker.

One example being StepMania 3.9 which, for god knows what reason, would crackle on my system with dmix unless I let it think it was getting exclusive hardware access via OSS and called it via aoss.

(I'm also planning to write an LD_PRELOAD shim for SDL_ListModes and SDL_SetVideoMode to trick Dungeons of Dredmor into allowing windowed resolutions other than the 2560x1024 that I've locked my dual-monitor desktop at.)

4. When Wayland comes out, games like Inescapable which statically-link against pre-Wayland OpenGL helper libraries will be stuck using XWayland unless the developer releases an update, they're using a version of SDL 2 with SDL_DYNAMIC_API, or someone loves the game enough to rewrite the engine from scratch.

Pretty much why I think bundling the libraries with the game is a better idea than statically link them to the binary.
I thought GOG already did this with at least some of the needed libraries?

Hello,

1) The deb files are scripted and have a predefined install folder that you can't change. I personally prefer the tarballs since I run my games on a separate hard disk and have more control in general.

2) Linux releases by GOG all have the start.sh, to make an easy out of the box experience. More often than not running the executable directly leads to the game not running properly or not running at all.

The reason for this is because some games come with the necessary libraries but can't use them without the help of the sh file. Basically the sh file "tells" the executable that the required libraries are in the folder and in turn the game runs correctly.

Also in answer to your question regarding the shortcuts, the deb installer automatically links the start.sh file. In most distros this can be done manually with a few clicks.

Sorry I'm usually not very good at explaining this stuff, I hope you get what i mean.

start.sh has --install and --uninstall options which will do the same things the deb does but for whatever location you unpacked it into.

In fact, looking at support/gog_com.shlib, it looks like it also powers .deb install and uninstall via the undocumented --install-deb and --uninstall-deb options.

may I ask what distribution you are using and what weird libs gave you such much trouble? Imho if we were to try and use the collective brainpower of these forums and collect the information how to "translate" the dependencies to other distributions, that would be a much better solution.
We could even put all that togethe as a script, which takes the dependencies on the game page as input and gives you back the relevant dependencies for your distribution.

The existence of a central package management system ist imo one of the major advantages of linux. Ignoring that system and shipping every game with all their dependencies would be rather sad :/