Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mightymike]

Congratulations on the update. So helpful!

[Iklistkel]

Iklistkel: Yeah, glibc compatibility is a problem, but hopefully it's not too hard to fix.  Don't give up hope yet :-)  Really you just need to get the correct versions of the libraries and stick them in the DF directory (and also set the LD_LIBRARY environment variable to use the libraries in that directory).

Is anybody organising this?  I could potentially help if there is a lack of expertise.  I don't think there is any particular reason to wait for Putnam to fix it.  We could just bung together the correct libs from more recent versions of debian along with the startup script that's in the community release and it would probably just work.

I'm not an expert, so If you fix I'll be very grateful =D

[lethosor]

Iklistkel: Yeah, glibc compatibility is a problem, but hopefully it's not too hard to fix.  Don't give up hope yet :-)  Really you just need to get the correct versions of the libraries and stick them in the DF directory (and also set the LD_LIBRARY environment variable to use the libraries in that directory).

Is anybody organising this?  I could potentially help if there is a lack of expertise.  I don't think there is any particular reason to wait for Putnam to fix it.  We could just bung together the correct libs from more recent versions of debian along with the startup script that's in the community release and it would probably just work.

Dumping a different libc.so into the DF directory is a good way to cause lots of crashes. See e.g. https://stackoverflow.com/q/21190908

I know people from DFHack have been talking with Putnam about improving compatibility by building on an older system, and/or with an older compiler. It's easier said than done because DF is actually using some C++20 features now that GCC 10 does not support. It is on Bay12's radar, though.

[A_Curious_Cat]

Whelp!

The good news is that I've finally purchased the Steam version (couldn't get itch.io to work...).

The bad news is that DF wants libc 2.34, and my distro only has 2.33.

Fun...

I've also tried using both proton 8.x and proton 7.x (I forget the minor version numbers...), but I haven't gotten it to work with those either...

[alpha]

libSDL2_image-2.0.so.0 is available in Debian 10 ("Buster") in the official package repo: https://packages.debian.org/buster/libsdl2-image-2.0-0

Installing it is a matter of running "apt install libsdl2-image-2.0-0"

the "missing" libraries are:

./dwarfort: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /DF/play_linux/libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by /DF/play_linux/libg_src_lib.so)


The system has all those libs. Just not those versions.

libc is a harder problem here.

It should be (theoretically, I haven't tried it myself, and I don't have a buster install to do so) possible to fix this by:

1) download http://ftp.gnu.org/gnu/glibc/glibc-2.34.tar.gz and extract somewhere, and build it from sources, then install it for example into df/libc2.34
2) apt install patchel
3) using patchelf, modify two properties of the dwarfort binary (note that paths _MUST_ be absolute):

As for libstdc++ part of the problem, it should be fixable by downloading the appropriate version of the .so and placing it in the same directory where dwarfort is located.

Or, you could update your Debian 10 to the current stable version (12) and all of this would be fixed.


Just upgrade your system, fixing this would take too much time and effort and may not be ultimately possible.

[laularukyrumo]

Glad to see a new update!
Less glad to see no mention of bridges and the inability to choose a direction for them in Classic.

[lethosor]

Less glad to see no mention of bridges and the inability to choose a direction for them in Classic.

My understanding is that you can change that in classic, you just can't see the buttons. Not particularly easy, I know.

libc is a harder problem here.

It should be (theoretically, I haven't tried it myself, and I don't have a buster install to do so) possible to fix this by:

1) download http://ftp.gnu.org/gnu/glibc/glibc-2.34.tar.gz and extract somewhere, for example into df/libc2.34
2) apt install patchelf
3) using patchelf, modify two properties of the dwarfort binary (note that paths _MUST_ be absolute):

Code: [Select]

$ patchelf --set-interpreter /absolute/path/to/your/df/libc2.34/ld-linux.so.2 dwarfort
$ patchelf --add-rpath /absolute/path/to/your/df/libc2.34 dwarfort

As for libstdc++ part of the problem, it should be fixable by downloading the appropriate version of the .so and placing it in the same directory where dwarfort is located.

Or, you could update your Debian 10 to the current stable version (12) and all of this would be fixed.

Replacing libc is what I said would likely be unsafe a couple posts above yours. Also, that archive you linked is just the source - you would also need to compile glibc if you went through those steps.

[alpha]

Replacing libc is what I said would likely be unsafe a couple posts above yours. Also, that archive you linked is just the source - you would also need to compile glibc if you went through those steps.

What I described is not replacing libc, but installing a new one, specifically for the purpose of running DF with it. I don't think this can cause any problems for your system, at worst your DF will still be not working.

But yeah, I did not check if the archive contains binaries or code. Building it from source should not be too difficult.

[lethosor]

What I described is not replacing libc, but installing a new one, specifically for the purpose of running DF with it. I don't think this can cause any problems for your system, at worst your DF will still be not working.

That's exactly what I meant by "replacing glibc" - replacing the glibc that DF is using. Replacing it system-wide would be even worse and didn't cross my mind. I was using the word "replacing" interchangeably - sorry for the confusion:

Dumping a different libc.so into the DF directory is a good way to cause lots of crashes. See e.g. https://stackoverflow.com/q/21190908

Part of the reason this is unsafe, from my understanding, is that glibc integrates tightly with certain system calls. If your kernel provides different system calls than the kernel glibc was built for, bad things will happen.

[alpha]

Part of the reason this is unsafe, from my understanding, is that glibc integrates tightly with certain system calls. If your kernel provides different system calls than the kernel glibc was built for, bad things will happen.

If you build libc from sources, this should not be a problem, as during the build process information about syscalls will be obtained from the kernel that is present on your system. See --with-headers here https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html

[Iklistkel]

So... I guess I'll stick with the old versions...

[lethosor]

I mean, this is a fair point:

If you build libc from sources, this should not be a problem, as during the build process information about syscalls will be obtained from the kernel that is present on your system. See --with-headers here https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html

It might work. But it also might crash, and if it does, you should probably consider this the reason and avoid reporting it through the official bug-reporting channels.

I realize this isn't great for older distros. DFHack folks are still looking at how we can help with improving compatibility, and I know Putnam has been too, but it could still be a bit before something is figured out.

[alpha]

I have launched Debian 10 in a virtual machine and tried to fix the missing librariers problem with the above instructions, however even though I got to the point where the program actually launches, it just exits a second later after some "Broken unicode: [KEY:]" lines, with exit code 127. At this point I think it's not worth the time. Just upgrade your system.