The International Simutrans Forum

 

Author Topic: libbz2.so.1.0 on fedora 35 not found  (Read 125 times)

0 Members and 1 Guest are viewing this topic.

Offline Yona-TYT

  • Devotee
  • *
  • Posts: 1824
    • Simutrans-BLOG
  • Languages: ES
libbz2.so.1.0 on fedora 35 not found
« on: January 14, 2022, 06:02:32 AM »
Install the package that I tested from this library in fedora, but it turns out that the symbolic link is called "libbz2.so.1", but simutrans searches for it is "libbz2.so.1.0", is it possible to improve this?.
Code: [Select]
[yonatyt@fedora ~]$ '/home/yonatyt/Descargas/simulinux-x64-nightly/simutrans/simutrans'
/home/yonatyt/Descargas/simulinux-x64-nightly/simutrans/simutrans: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

I was able to fix this simply by creating a new symbolic link called "libbz2.so.1.0 ", but not everyone knows how to do that. 

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: libbz2.so.1.0 on fedora 35 not found
« Reply #1 on: January 14, 2022, 01:30:46 PM »
This is a known problem. Unfortunately, no easy solution for non-techy users. The first time I downloaded simutrans from SourceForge I faced a similar issue but with miniupnpc. But to known problems, known solutions! There's actually 3 that comes to my mind:

1. The "lazy" solution: Include necessary libraries in the release(in a separate "lib" directory). Then start simutrans from a script file (simutrans.sh) with the following command:
Code: [Select]
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:lib/" simutrans This adds the bundled libraries at the end of the LD_LIBRARY_PATH, so they will be used if it they are not found in your system. This is what the Steam version actually does to address this problem.

2. The "clean" solution: Include necessary libraries in the release(in a separate "lib" directory). But first, in the compilation set the RPATH to the lib directory. The advantage of this is that you don't need an extra launcher script. Actually this was the solution I used at first when assuming control of Steam, and this is what OpenTTD does, for example.

3. The "bloated" solution: use flatpak or another solution for distribution. I call it bloated because these solutions comes with its own runtime, which can take up to 1GB additional download (which is hard to justify if you are not using flatpak for anything more than Simutrans). I was interesting in flatpak recently as an additional option to consider, but our main method of distribution it should not be.

Then why did I choose the "lazy" solution over the "clean" one? Well, because I only had direct control over the stable releases build process, I could only set the RPATH for them. Any other non-Steam Simutrans (nightly, extended) that I would want to include could only benefit from the "lazy" option, so I switched to this for every version.

Maybe it's time for me to work on applying the RPATH solution upstream, if there is a demand for it.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1447
Re: libbz2.so.1.0 on fedora 35 not found
« Reply #2 on: January 14, 2022, 01:40:37 PM »
4. Static link and be done with it...   If you're distributing a 'private' copy of the shared libraries anyway (1. and 2.), what's the benefit over just linking them into the binary?

Offline Roboron

  • Devotee
  • *
  • Posts: 440
    • Las Galácticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: libbz2.so.1.0 on fedora 35 not found
« Reply #3 on: January 14, 2022, 04:06:16 PM »
Well, for 1-2 there's a benefit for us: you don't have to compile the static versions of libraries. Since linux distributions usually only package dynamic libraries, that's an extra effort we would need to do, I think.