News:

Want to praise Simutrans?
Your feedback is important for us ;D.

libbz2.so.1.0 on fedora 35 not found

Started by Yona-TYT, January 14, 2022, 06:02:32 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Yona-TYT

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?.
[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. 

Roboron

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

TurfIt

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?

Roboron

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.

Roboron

After some work on the RPATH solution, I have something working with GitHub CI. Was not as easy, as Ubuntu likes to bring down tons of useless libraries that my Arch system does not (following the very same procedure) and I had to filter them alongside other common linux libraries (such as libc). But it is a good idea to use Ubuntu LTS for distribution, so I hope it was worth it.

@YonaTYT please try this in your Fedora https://github.com/Roboron3042/simutrans-build/releases/download/Nightly/simulinux-x64-nightly.zip

I've tested it already on Debian and Ubuntu, but those two are pretty similar. And my Arch system is not a clean installation, so not good for testing. The output of ldd simutrans would also be appreciated to see, specially if there are any problems.

prissi

#5
EDIT:
It seems indeed that Linux is now so broken, that the easiest way is to distribute tons of MB of unused libraries instead of allowing static linking. It seems like in flatpack and docker times, being environmentally friendly and do not waste has become totally obsolete.

I found http://statifier.sourceforge.net/ but that is about the same as distribute the libaries with the program.

Yona-TYT

Crash while the loading bar is about to end.

(gdb) where
#0  __memmove_sse2_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:413
#1  0x00005555559f1e8d in money_to_string(char*, double, bool) ()
#2  0x00005555557e07c3 in win_display_flush(double) ()
#3  0xff2cffae132c0000 in ?? ()
#4  0x7b2cd000002c7fff in ?? ()
#5  0x002c0055552c557e in ?? ()
#6  0x6a2c0000002c0000 in ?? ()
#7  0x002c0001e22c4108 in ?? ()
#8  0x4e2c0000002c0100 in ?? ()
#9  0xae2c99e5c12cddc4 in ?? ()
#10 0x022cffffff2cffff in ?? ()
#11 0x002c0002c02c0000 in ?? ()
#12 0x022c3000002c0030 in ?? ()
#13 0x002c0002002c0000 in ?? ()
#14 0x002c0000002c0033 in ?? ()
#15 0x002c0002c02c0000 in ?? ()
#16 0x002c0000002c0000 in ?? ()
#17 0x002c0000002c0000 in ?? ()
#18 0x002c0000002c0020 in ?? ()
#19 0x552c6b53a12c0000 in ?? ()
#20 0xb02c8400002c5555 in ?? ()
#21 0x002c00002c2cffff in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--



It also seems that my system doesn't find a lot of debugging libraries (it used to find all of them before):
(gdb) run
Starting program: /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/simutrans2
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libpng16.so.16
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/c5/07cdf66b829f661543cd22c32479c8df09be06.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libz.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/7a/04c793a2ce7b847f43840ca650e0d9dd35389d.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libbz2.so.1.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/f8/e13291f0c24f1c51bd2e7c50a3490f82f66d20.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libminiupnpc.so.17
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/34/103017b6be67cde31fab7329838cde27dfc62a.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libSDL2-2.0.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/8c/c50993332afbd2b8fa2d18b4d811a14fb2aeaf.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libfreetype.so.6
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/41/b7f69ff4d29aeaad7bd4f548d026e8eaedca84.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libzstd.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/34/1119544f80e4c9fb9beab13ed707911a37bdad.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libfluidsynth.so.2
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/ab/0d07f288dcae826e5cd7507d2e7f54a47e663f.debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libglib-2.0.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/2c/1d2f9d4a08c71a36797aeb246ab7ae377934ea.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libgmodule-2.0.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/e9/2f143d0958679164ec3b1346d32fc7f643538e.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libsndfile.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/5b/dbc86ce4bd1e8fa8c1baecd17ae8a15b9a52d2.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libreadline.so.8
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b2/6b37d04de63161632027760514b3256bf2062d.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libinstpatch-1.0.so.2
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/ed/29c4845479370c6a9a20760464e726936f5826.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libgobject-2.0.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/b6/a09d7325b2a42f12c98436e7bf0ddba5a7c79a.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libpcre.so.3
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/ac/83711fbcb2725ad376ca8f8c947f6a782e7a65.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libFLAC.so.8
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/bc/759fbc560e0f8f395120f03197c38c95e7c12c.debug
warning: the debug information found in "/home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libogg.so.0.8.4" does not match "/home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libogg.so.0" (CRC mismatch).

Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libogg.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/86/1e2c0ca7f6c2ddfdffaf0ea9831e9ae84a44ac.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libvorbis.so.0
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/74/a34a3109cadabf23e227e6931e29e8ee792984.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libvorbisenc.so.2
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/11/9e45e995f87594b12736907d734ffe962118f8.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libtinfo.so.6
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/bc/bfd3419068cde1f3b77da5602c0850cd79ffac.debug
Missing separate debuginfo for /home/yonatyt/Descargas/simulinux-x64-nightly(4)/simutrans/libs/libffi.so.7
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/a1/80ef72f4b968d97ff1fe77277012abe952d8ac.debug
[New Thread 0x7fffe11d7640 (LWP 3603)]
[New Thread 0x7fffe02d1640 (LWP 3607)]
[New Thread 0x7fffd31ff640 (LWP 3608)]
[New Thread 0x7fffd24f5640 (LWP 3609)]

Thread 1 "simutrans2" received signal SIGSEGV, Segmentation fault.
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:413
413        movw    %cx, -2(%rdi,%rdx)





Roboron

That crash is unrelated with this, see https://forum.simutrans.com/index.php/topic,21304.0.html (it was fixed in r10414, but I based this fork on r10413 :^) ). You can try again today, I incorporated the fix (same link).

Anyway, since the game started, it means it found all the necessary libraries. So we could green-light this. Still, please I'd like to see your output of "ldd simutrans".

Quote from: prissi on January 27, 2022, 06:31:56 AMIt seems like in flatpack and docker times, being environmentally friendly and do not waste has become totally obsolete.

I have to agree... Unfortunately. Well, at least this is a compromise solution, not as good as it could be but definitely not as bad as running flatpack or docker. It's "only" 8 MB of extra download and not 800.

prissi

Actually libbz2 is the most easy to link statically; for a long time we had to compile them even ourselves for windows.

Roboron

#9
I have committed the changes previously mentioned, and switched the GNU/Linux CI build to CMake so it now bundles the libraries. I used this system for the 123.0.1 release on Steam and so far no one complained (but due to the Runtime, a missing dependency was less likely to happen). Hopefully this end these kind of issues for now, at least for common distros.

prissi

Thank you. Since Simutrans is part of most distros, the problem is luckily only there for the nightlies. (Also libbz2 and miniunonc could be easilly statically built each time and linked, if those are the only ones that make trouble).

Distributing libSDL seems like not so a good idea, at least considering bug fixes which may be need to start on new graphic hardware. Also it would distribute all wayland libs as well, if the SDL would have been built with this. Maybe one should rather use a positive list of uncommon libaries in simutrans?

And finally I am not sure we are allowed to distribute copies of the actual libaries, omitting all license etc txt for those. This is very different from static linking. Maybe we need also to copy the actual licenses of those libraries and the current Ubuntu?

Also what regex is "libstdc...so"? Also I vaguely remeber that there had bee even problems if a libstrc++ between distributions.

makie

#11
The sense of libSDL is to abstract the API of the various systems.
If you bundle libSDL you move the problem of compatibility to the various layer before libSDL.
The libSDL is device depended, so bundling contradict the sense of it.

So compiling against the various versions of libSDL2 and offer the program for various common lib-versions is the better way. i think.
Or if the program had a detection of the versions and adapts to it.

Roboron

#12
Quote from: prissi on February 06, 2022, 05:11:10 AM(Also libbz2 and miniunonc could be easilly statically built each time and linked, if those are the only ones that make trouble).

Miniupnpc is definitely the most uncommon of the libraries, only used by a few packages in my distro (0.a.d, dolphin-emu and retroarch being the most common). But the only problem is not the library not being in the user's system. Bzip2 was actually in Yona's Fedora, but the *specific* version required by Simutrans was not. This could happen any time with any library when there is a major version mismatch between the build system and the target system. Just as we talk, Extended release is suffering a similar problem but with libpng (even worse, because a simple symlink can't fix it).

For this reason, leaving out SDL2 is a good idea if we know for sure that no backwards-incompatible versions are going to be released. So far since the release of SDL2.0.0 (2013) only minor versions have been released, and my system will happily link to the new SDL2.0.20 instead. So it is probably a good idea, looking at the history. I can agree on that. Let's try.

About the availability of SDL2 in various distributions, I don't think there will be any problem. At least on Arch it shows as a dependency of ffmpeg, and that should make it virtually available in every system.

Quote from: prissi on February 06, 2022, 05:11:10 AMAnd finally I am not sure we are allowed to distribute copies of the actual libaries, omitting all license etc txt for those

At the very least we should add an exception in the simutrans license (just as we do for one of the fonts), but including the licenses is also desirable. However, I don't know if there is an easy, automated way of doing that, because it can be quite a bit of work hunting for every license.

List of libraries after excluding SDL2:

libFLAC
libbz2
libffi
libfluidsynth
libfreetype
libglib
libgmodule
libgobject
libinstpatch
libminiupnpc
libogg
libpcre
libpng
libreadline
libsndfile
libtinfo
libvorbis
libvorbisenc
libz
libzstd

prissi

libz is virtually required by almost any software on Linux.

The libbz2 naming problem goes back about 11 years at least, I found something in StackOverflow from 2009 ...

Roboron

#14
I went further to reduce the number of dependencies and found that compiling fluidsynth instead of using the Ubuntu package helps quite a lot. If we use only the features we need (sdl2 basically), we don't need to filter out all the audio stuff (pulseaudio, pavucontrol, jack...), it becomes obviously more portable, and it reduces the final included dependencies count by 5.

Quote from: prissi on February 06, 2022, 01:59:00 PMlibz is virtually required by almost any software on Linux.

And it seems to have reached its end-of-live (last release 5 years ago), so we can probably count on it to stay in a stable versioning. Let's keep it out, we can always change it if a new version is released in the future. I've also discovered that libgomp is part of gcc libs, so that is presumably not needed either.

I've been taking a look at licenses in Ubuntu. Unfortunately, the licenses included are not ready for human readers, so they are not very useful:

=> http://changelogs.ubuntu.com/changelogs/pool/main/f/flac/flac_1.3.3-1build1/copyright

Other projects seems to maintain a folder with libraries licenses, and they copy them alongside the libraries. For example:

=> https://github.com/longturn/freeciv21/tree/master/dist/licenses

What do you think? What's the approach we should take with licenses? This is the final list after mentioned changes. I've included a link to their licenses in case it is useful.














libFLAChttps://raw.githubusercontent.com/xiph/flac/master/COPYING.Xiph
libbz2http://sourceware.org/git/?p=bzip2.git;a=blob_plain;f=LICENSE;hb=HEAD
libfluidsynthhttps://raw.githubusercontent.com/FluidSynth/fluidsynth/master/LICENSE
libfreetypehttps://raw.githubusercontent.com/aseprite/freetype2/master/docs/LICENSE.TXT
libglibhttps://raw.githubusercontent.com/GNOME/glib/main/COPYING
libminiupnpchttps://raw.githubusercontent.com/miniupnp/miniupnp/master/LICENSE
libogghttps://raw.githubusercontent.com/gcp/libogg/master/COPYING
libpcrehttps://raw.githubusercontent.com/vmg/libpcre/master/LICENCE
libpnghttps://sourceforge.net/p/libpng/code/ci/master/tree/LICENSE?format=raw
libsndfilehttps://raw.githubusercontent.com/libsndfile/libsndfile/master/COPYING
libvorbis-{enc}https://raw.githubusercontent.com/xiph/vorbis/master/COPYING
libzstdhttps://raw.githubusercontent.com/facebook/zstd/dev/COPYING


prissi

Maybe we need just to list these like this then.

Also, to make setup compiling a little easier (for people using source packages) I added a setup-development.sh script, which would also compile and prepare everything for a dummy user (that has sudo privileges on Ubuntu or knows the root password on Debian).

Not sure what Linux you are using, but please give it a spin.

Roboron

#16
In r10474, I added the list to simutrans/license.txt

Quote from: prissi on February 07, 2022, 02:41:50 AMI added a setup-development.sh script

The "sudo" inside setup-debian.sh uses an unknown option (-y), but you innecessarily added "sudo" to the setup-debian.sh (it is already called as sudo/su from the main script). Nonetheless, it kept going and compiled simutrans after installing dependencies (without upgrading the system). However, it failed at linking looking for "-ldrm" and "-lgbm" (seem something related to graphics). Then I:

1) Run upgrade manually. And tried again. Didn't work, same problem.
2) Run CMake instead. That did work.
3) Run make manually. That did not work either.

There must be something wrong with the makefile. EDIT: It is because it sets STATIC = 1 by default. That makes it fail (Debian 11).

I pushed the sudo fixes and added the script to the readme, but I leave the STATIC issue to you.

prissi

#17
I compiled on Ubuntu and Debian10 so I did not caught it. Still STATIC just adds "-static-libgcc -static-libstdc++ -static" to the linker and " -DPNG_STATIC -DZLIB_STATIC" and "--static" to the config libary call of freetype. The compiler/linker switches must work, or somebody else would have complained by now. "-ldrm" so we link not to rights management?!? Sounds like Freetype again. Maybe it is time to switch to SDL2font.

ldd with STATIC reveals that this is entirely ignored on Debian10.

I was wondering I the default download for most OS should not be a script that executes this apt script (if also tested on other distributions) and then downloads, compiles and installs simutrans. That would take care of all the dependencies.

Also I noted that the revision in the Unbuntu and Debian default package is 0. I think the zipsrc.sh scipt need to freeze the current revision.

EDIT: I could statically link the posix backend, and there is SDL2 as static as well. Static linking should work. but pkg-config is broken for libSDL2. It wants to statically link to libasound, which does not exist. So libSDL2 needs dynamic linking, but then it is probably there in all systems.

I read a lot why not doing this and instead packaging the dynamic libs. Somehow. packaging the dynamic libs seems like combining the disadvantages of dynamic libs and static linking, because the program will use then outdated libs as well but will be even bigger.

EDIT2:
I could statically link everything but stdc6++, m (math), and SDL2 using this (i.e. removing -lm from the countless later apperances)
-lm -lpthread -Wl,-Bstatic -lbz2 -lfreetype -lpng16 -lminiupnpc -lzstd -lpthread -lz -lpng -Wl,-Bdynamic -lSDL2 -static-libgcc -static-libstdc++
ldd sim show then this
linux-vdso.so.1 (0x00007ffe6cfc9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f460f068000)
libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f460ef13000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f460edc4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f460ebd2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f460f9a3000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f460ead7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f460ead1000)
libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f460ea7a000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f460e93d000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f460e928000)
libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f460e91b000)
libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f460e916000)
libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007f460e904000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f460e8f5000)
libXss.so.1 => /lib/x86_64-linux-gnu/libXss.so.1 (0x00007f460e8f0000)
libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f460e8e9000)
libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f460e8e4000)
libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f460e8d3000)
libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f460e8c8000)
libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f460e884000)
libpulsecommon-13.99.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so (0x00007f460e802000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f460e7b1000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f460e787000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f460e57d000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f460e573000)
libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f460e567000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f460e4b8000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f460e4ac000)
libsndfile.so.1 => /lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f460e42e000)
libasyncns.so.0 => /lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f460e226000)
libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f460e211000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f460e206000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f460e200000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f460e1f8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f460e1cd000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f460e1ac000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f460e08e000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f460e071000)
libFLAC.so.8 => /lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f460e033000)
libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007f460e026000)
libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f460dff6000)
libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f460df4b000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f460df2f000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f460df15000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f460def2000)

Roboron

#18
Quote from: prissi on February 08, 2022, 12:07:45 AMI read a lot why not doing this and instead packaging the dynamic libs. Somehow. packaging the dynamic libs seems like combining the disadvantages of dynamic libs and static linking, because the program will use then outdated libs as well but will be even bigger.

Yeah, I've stumbled upon many threads advising against static linking, too. Therefore this solution. I must admit, I don't see much difference with static linking (well, that you can actually use the system library instead by replacing/removing the bundled one), but then I don't have as many experience as the people discouraging it (distro developers and the like). However, if one wants to prioritize system libraries while linking dynamically, a startup script and setting LD_LIBRARY_PATH should be the way to go, instead of setting the RPATH.

Quote from: prissi on February 08, 2022, 12:07:45 AMStatic linking should work. but pkg-config is broken for libSDL2. It wants to statically link to libasound, which does not exist.

How does it not? It is there in the ldd output.

Quote from: prissi on February 08, 2022, 12:07:45 AMldd sim show then this

Fluidsynth is missing from the flags, did you compile with it? (it seems so, because I can spot some of its dependencies in ldd which have not been linked statically). Otherwise, SDL2 brings a ****-ton of dependencies as usual, but the main libraries are not there so you at least succeeded on that.


Anyway, if you want to change the current solution, feel free to do so. As long as it works, I don't really care how. I'll focus next on look how to deploy Simutrans on Flatpak, as an alternative.

prissi

#19
Since the only libaries making trouble is freetype minupnpc and bz2, which link statically with little effort, I think I will change the makefile that way. I have not tried fluidsynth, since you said you compiled it yourself.

pkg-config sdl2 -libs --static want to tink libasound, even if it may no need it ... lets see if it links without.

Add fluidsynth did not compile on buster:
n function 'bool dr_init_midi()':
src/simutrans/music/fluidsynth.cc:191:53: error: no matches converting function 'fluid_log' to type 'fluid_log_function_t' {aka 'void (*)(int, char*, void*)'}
  fluid_set_log_function(FLUID_PANIC, fluid_log, NULL);
                                                     ^
src/simutrans/music/fluidsynth.cc:177:13: note: candidates are: 'void fluid_log(int, const char*, void*)'
static void fluid_log(int level, const char *message, void *)
             ^~~~~~~~~


I tried cmake, but buster only has cmake 3.13 (even though it is not that old). Making cmake as universal and simple a configure seems still a way to go. People still use Debian 9, and it is still supported.

EDIT2:
Compiled fluidsynth with Makefile. According to the documentation on the itnernet the log function wants char, not const char. Not sure how this could compile. Also including SDL will no longer work if not installed. As expected fluidsynth and libSDL2 are the only one needing dynamic linking.

Roboron

I don't know if the CMake version is the problem, but the fluidsynth version surely will. Debian buster is using the legacy 1.x.x fluidsynth, while simutrans requires 2.1 (because of sdl2 support). That may explain the compiling errors also.

prissi

#21
The version I had, did not compile, because I had not installed SDL1.2. It compiles with libSDL2 only. And I used your setup script. Most people will not compile fluidsyth themselves ...

I submitted a define for the logging to take care of that, so it should compile out of the box and on github.

EDIT: I found why people advocate shared libs: The LGPL needs this, as stated in the fluidsynth documentation, because the user must be able to replace the libary (as if he ever will do this.) Especially for OpenSource, that requirement is not needed.


Roboron

Now if I try to compile with the Makefile in my Arch system I get the following:

/usr/bin/ld: cannot find -lfreetype: No such file or directory
/usr/bin/ld: cannot find -lbz2: No such file or directory
/usr/bin/ld: cannot find -lpng16: No such file or directory
/usr/bin/ld: cannot find -lharfbuzz: No such file or directory
/usr/bin/ld: cannot find -lgraphite2: No such file or directory
/usr/bin/ld: cannot find -lglib-2.0: No such file or directory
/usr/bin/ld: cannot find -lpcre: No such file or directory
/usr/bin/ld: cannot find -lbrotlidec: No such file or directory
/usr/bin/ld: cannot find -lbrotlicommon: No such file or directory
/usr/bin/ld: cannot find -lminiupnpc: No such file or directory
/usr/bin/ld: cannot find -lzstd: No such file or directory
/usr/bin/ld: cannot find -lbz2: No such file or directory
/usr/bin/ld: cannot find -lpng: No such file or directory


Unless I manually set STATIC:=0. I suggest to set STATIC:=0 by default given that it causes problems on some systems.

prissi

Ok, its Arch's policy not provide statics, if there is a shared one. So much for freedom with Linux, sigh.

The Makefile can set STATIC=0 as default, since it is intended for self-compilation. However, for distribution STATIC=1 is clearly the better choice as it returns the dependencies dramatically to essentially LibSDL2 and libfliudsynth.