Get this when i attempt to run the game via start.sh

Torment: error while loading shared libraries: libjson.so.0: cannot open shared object file: No such file or directory

Ubuntu 16.04, 64 bit, RX480 on a haswell machine.


edit:

fixed it myself:

# sudo apt install libjson0:i386

So, I'm having this same error, except running the apt install command is just telling me that it can't locate the package libjson0:386.
I tried to find the package, and there's nothing available that is even similar to it, so now I'm kind of stuck. Ideas?

Okay, So it turns out on Ubuntu 16.10 I guess they changed the name to libjson-c3. Installing the package for that " sudo apt install libjson-c3:i386 " will install the required files, but they'll be named incorrectly so the game will still complain.
I fixed that by going to /lib/i386-linux-gnu/ and simlinking the new file to the old name " sudo ln -s libjson-c.so.3 libjson.so.0 " Which works, but is horribly hacked together...

i have the same issue and the same os configuration,
but your fix is not applied to me ((
> $ sudo apt-get install libjson0
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package libjson0

what else I may try?

So, maybe it's better to add a post here too (original post).

In general, the easiest way without breaking the system is to download libjson. Extract its contents (DON'T INSTALL) and then copy the missing file to the lib folder inside the game's folder.

start.sh script should take care loading libraries in that folder. If not add the following to the beginning of the script (but after the line starting with #!):
# Add shared object libraries to path
export LD_LIBRARY_PATH=/home/[your user name]/GOG\ Games/[game installation folder]/lib

You will need the i386 version.

If Icewind Dale EE works fine for you, I can confirm that the missing library is there. Just copy these three files (actually a file and two soft links) to the lib folder inside Torment EE installation's one.

As I've also posted here:
The difference in loading the library for the specific game, is that you can use different versions for other software, without collisions which could result in breaking the system. In the worst case, just the specific application will crash.

I hope this helps and everyone may enjoy the game.

I just downloaded and launched the game on Mint 18.1 x86_64.
Here are the complete steps, assuming the game is installed in the default folder.
This approach does not make any changes to the system (all commands are unprivileged, no system wide library installation). We will load the required library for the specific application (actually for the specific shell session).

--------------------
UPDATE: Generally the recommended approach is to solve dependencies using the distribution's package management tool.
This approach is a general method to fix library dependency issues, such as in cases like unsupported (by GOG) distributions or supported distributions which provide a newer incompatible library version, or has removed the library completely.
Of course, interested users may participate in the complete discussion taking place here.
--------------------

Create a lib folder into Torment's installation folder:
$ cd ~/GOG\ Games/Planescape\ Torment\ Enhanced\ Edition/
$ mkdir lib

Download libjson-c2.
I strongly recommend to check the integrity of the downloaded file before continue.

Navigate to the folder you have downloaded the deb file.
Extract deb file:
$ dpkg-deb -x libjson-c2_0.11-4ubuntu2_i386.deb libjson-c2_0.11-4ubuntu2_i386

Copy the shared object file to lib folder:
$ cd libjson-c2_0.11-4ubuntu2_i386/lib/i386-linux-gnu/
$ cp libjson-c.so.2.0.0 ~/GOG\ Games/Planescape\ Torment\ Enhanced\ Edition/lib/

Create the required symbolic links:
$ cd ~/GOG\ Games/Planescape\ Torment\ Enhanced\ Edition/lib/
$ ln -s libjson-c.so.2.0.0 libjson-c.so.2
$ ln -s libjson-c.so.2.0.0 libjson.so.0

Edit start.sh script (I used nano, but feel free to use a graphical editor):
$ cd ~/GOG\ Games/Planescape\ Torment\ Enhanced\ Edition/
Maybe you'd like to take a backup before editing:
$ cp start.sh start.sh.back
$ nano start.sh

Add the part in bold text. It should look like: Press ctrl+x -> y -> Enter to save the file.

Now all have been set. You may play the game:
./start.sh

Enjoy the game!

Your approach and assertions left me with some questions. They are meant objectively and polite, and I may even have misunderstood you. How is that easier than one single command? How is using additional versions of a library less prone to collisions than just using the one that is meant and tested for the system?

How is the location of a library relevant for the extend of the damage it can do? That is taken care of automatically by the :i386 suffix after a package's name in the apt command. Linux Mint 18.1 uses the Ubuntu 16.04 repositories so the apt command should work there also.

To mention it here again for all who didn't read the other thread: All packages installed from the official repositories by the package management are checked for tampering by their cryptographic signature against the public keys that come with the system. This security measure is undermined by manual installation.

Please don't take me wrong. In my eyes, your method may be valid if an application needs (specific versions of) libraries that are not provided by the system itself. But in all other cases, the system's own libraries should be used to avoid the collisions you mentioned and to minimize the amount of foreign software in the system. The central repositories and the secure package management are two of Linux' long-time strengths that other OS' lack or are adopting only slowly, like the "app stores" they promote as a modern ingenuity nowadays.

I respect your valiant effort in helping others. I just don't recommend promoting procedures to unknowledgeable people that I find unnecessary in most cases and a potential security risk.

Happy holidays.

Hi V4V,

don't worry, there's no misunderstanding. Your questions are reasonable and productive.

I agree that a single command using the distribution's management tool is the easiest method. Just a command and all are taken care by the tool.
The problem here is that it doesn't work all the times. Even some Ubuntu derivatives like Mint are allergic to 32 bit libraries for 64 bit systems. I had to search my old post for this:
https://www.gog.com/forum/general/release_turmoil_28c31/post42
https://www.gog.com/forum/general/release_turmoil_28c31/post47

What I suggest is not the easiest way - period, but the easiest way without breaking the system. That way is also possible to solve library dependencies using other distributions' shared objects, like Debian directly (not recommended of course, but it could be used).

System wide libraries are loaded by the system on every user login by scripts with elevated effective user privileges.
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

On the other hand by loading the libraries for the specific shell session (given we have checked their integrity and the process has normal user privileges) memory access is restricted by the kernel.

The application may crash with a segmentation fault (memory access error), but it won't be fatal for the whole system.

In general Linux distributions are a kernel and compilations of packages, which have been tested together for functionality and security and they don't break the system. So, it's better to stay with this, but it's not always a working solution.

The temporary library loading technique (it could be also overriding) has been used extensively in many cases, some of which are GOG games!

Let's take Icewind Dale EE for example (chances are that many users reading this thread own that game too): If you'd like to read the scripts further, you'll see that GOG does the same thing, as I suggested, without user notice!

EDIT: Happy Holidays!

it works for me.
thank you for realy detailed description.

A better idea might be for Beamdog to just statically link libjson into the game and then it won't even matter if the host platform has the file or not, but hey...

Thanks. I think you can understand my precaution in these days on the GOG forums. ;)

Also thank you for your detailed answer and even digging through your old posts. I'm left with a few comments: But aren't you putting the exception in the place of the norm? I presume that in most cases, the apt command will be the easiest way without breaking the system. In many years on multiple machines running different Ubuntu versions (always LTS versions, though) I've never had a crashing game do anything to the system. Anecdotal evidence, I know ;) but I think it's not that far from reality. I wasn't sure on that, thanks for the clarification. But if an application using a shared library crashes, does that (usually) anything to the library and its elevated accessed memory? I'm trying to gauge the probabilities here. I absolutely second that. But it doesn't seem to match your repeated statement about your method being the "easiest way without breaking the system" – it may be, but only on some systems that have problems with the standard way.

In summary, I don't have that much of a problem with your method, mainly with your wording that implies a universal need for it that in my opinion doesn't exist. How about giving at least users with Ubuntu 16.04 as in throAU's case the apt command with the manual method as an alternative for remaining problems? Yeah, I noticed that by myself a while ago. My argument applies to their approach all the same. I wonder why they left out libjson0:i386 in this case.

Again, thanks for your detailed and constructive answer. In these days with so much hate in the net, praise for friendliness is more important than ever, I think. :) This, but first and foremost, they could provide software packages (.deb for Ubuntu and all other Debian-based distros) to let the package manager install all needed libraries automatically. They could provide the .sh version in addition for non-deb distros they don't support officially anyway.

edit: typo

I've edited that post already! :-) libjson is under MIT license and may be statically linked.
Static linking could create more problems than it solves for supporting the software though.

Making many installation options available is great, but I'm not sure how it looks from GOG's business perspective.

I prefer distro-agnostic approaches. I'd like the freedom to switch between distributions.

My main system is FreeBSD. I boot on Linux for games and some other really nice tools. My first distro was Debian 3.0, then I took the rpm way (openSUSE, Fedora), a few time on Gentoo and now back in the apt way (Debian, Mint)! :-)

EDIT: Fix syntax.

Sorry for answering this late. To cite Blake Smith from Monstertalk, "I'm a pro at crastinating." :*)

@vanchann: Thank you for updating your post and the very pleasant conversation.

@thruAU: My apologies for starting a debate of principles in your thread.

Have a nice weekend.

I've added a section about this issue to the "Known Issues" list on the Infinity Engine page on the GOG Community Wiki.

It already lists a bunch of other Linux issues and workarounds for these games.

Hopefully this helps other users.

I'm having a similar issue (Debian). Basically, I tried installing libssl1.0.0:i386 like suggested, but was told that it had no installation canddiate. I then tried providing local replacements in a lib directory, but that caused a segfault when I tried to start the game. I'm at a bit of a loss what to do here.