Gzdoom "portable". Why is it not portable?

[bejiitas_wrath]

Why does this happen on Linux? Is this because I am not running Ubuntu with 10000 snaps?

 

(jcartwright@2403-4800-25af-b00--2) 192.168.1.5 Doom  $ gzdoom/gzdoom -file eu.wad 
gzdoom/gzdoom: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by /home/jcartwright/Documents/Doom/gzdoom/libgcc_s.so.1)

Why does an exe always link to a certain library? Why not make it work with any? Is this even possible?

[Shepardus]

I'm pretty sure "version `GLIBC_2.35' not found" means it requires glibc 2.35 or newer, not exactly 2.35.

 

What distribution are you using? In my experience (with Fedora 39) the portable build launched but for some reason didn't have sound. Also the download linked on zdoom.org is still 4.11.3 despite the newest version being 4.12.2. There used to be an AppImage but it never worked quite right (I was never was able to launch it successfully). I wouldn't be surprised if some of the issues with the AppImage also affect the portable build. I just build from source on my desktop and use the Flatpak on my laptop (originally was using the Flatpak on both, but wanted to have multiple versions available so I could load some old savefiles).

[kalensar]

Right in line with what Shepardus said.

 

GZD 4.12 does not have the Portable linux up quite yet for whatever reason. They didnt say why but yeah thats whats up. They do have the Hard upgrade non-portable version available through software channel at least for my  Linux Mint potato. 

 

photo

Spoiler

 

Edited May 6, 2024 by kalensar

[bejiitas_wrath]

On 5/6/2024 at 5:02 PM, Shepardus said:

I'm pretty sure "version `GLIBC_2.35' not found" means it requires glibc 2.35 or newer, not exactly 2.35.

 

What distribution are you using? In my experience (with Fedora 39) the portable build launched but for some reason didn't have sound. Also the download linked on zdoom.org is still 4.11.3 despite the newest version being 4.12.2. There used to be an AppImage but it never worked quite right (I was never was able to launch it successfully). I wouldn't be surprised if some of the issues with the AppImage also affect the portable build. I just build from source on my desktop and use the Flatpak on my laptop (originally was using the Flatpak on both, but wanted to have multiple versions available so I could load some old savefiles).

Alma Linux 9.3. An update is available, so hopefully this can give me a newer glibc.

 

(jcartwright@2403-4800-25af-b00--2) 192.168.1.5 etc  $ ldd --version
ldd (GNU libc) 2.34
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

 

Edited May 9, 2024 by bejiitas_wrath
Added information.

[LuciferSam86]

Wasn't systems like Snap made for a avoiding this library hell? :) 

[Redneckerz]

Unless you are okay with it, i feel i should mention your first initial and your last name is clearly visible in the snippets you posted.

[Blzut3]

On 5/6/2024 at 3:36 AM, kalensar said:

non-portable version

As of late pretty much the practical difference between the "portable" build and the one in the deb is that the deb build expects the user to provide SDL2.  A .deb is just a .ar archive renamed, and inside is a data tarball (and some metadata that you can basically ignore since none of my packages do anything special).  Extract that data tarball and assuming you have SDL2 installed on your system it almost certainly work unless your distro is not glibc based or older than 2018.  All the dependencies are really commonly installed and very ABI stable.  I just don't officially support non-Debian based systems and you won't have the package manager taking care of everything automatically.  But realistically it will work just about everywhere.

 

On 5/8/2024 at 8:37 PM, bejiitas_wrath said:

Alma Linux 9.3. An update is available, so hopefully this can give me a newer glibc.

RHEL (and thus AlmaLinux) pretty much never rebase core components like this, so you'll be on glibc 2.34 until AlmaLinux 10 is released.  With some exceptions updates just patch/backport security fixes to the version they locked in.

 

In this case the portable binary appears to have been built against glibc 2.35 (I assume Ubuntu 22.04), so you would need a distro that's based on glibc 2.35 or newer to run it.  I'm a little surprised it didn't load the libc.so.6 included in the package which may work in your case.  Usually people have the opposite problem where their distro is based on a newer version of glibc, and the old glibc included in the package prevents the GPU drivers from loading.  (Aside: the build inside the .deb currently only requires glibc 2.27.)

 

On 5/6/2024 at 1:09 AM, bejiitas_wrath said:

Why does an exe always link to a certain library? Why not make it work with any? Is this even possible?

Just like supporting old versions of Windows, there are limits to how old of a version a maintainer can be bothered to support since supporting old stuff requires additional effort for a ever decreasing number of users.  RHEL (and thus AlmaLinux) has an annoying habit of locking in versions of stuff that's already a version or two old even at the time of the .0 release.  So in this case even though RHEL 9 is a month newer than Ubuntu 22.04 LTS, it's not compatible with binaries built with Ubuntu 22.04's SDK.

 

9 hours ago, LuciferSam86 said:

Wasn't systems like Snap made for a avoiding this library hell? :) 

Sort of, the tooling allows people to feel good not looking behind the curtain and makes it easier to do the right thing.  But fundamentally the problem here is that you have to load GPU drivers, which means that it must be possible to change out some core libraries since in the future you might need to load drivers that don't exist today.  All of these systems have some kind of runtime concept to do this.  That isn't to say that containerization doesn't solve a couple of dependency problems that can't be solved otherwise, but I think the cases are fewer than most people imagine.  (Note that this commentary is limited to dependency stuff, there are other merits to these systems.)

[smeghammer]

Slight aside here - I also run GZ on Ubuntu (not portable) as well as Slade native. 

 

There are regularly Linux'y topics, but scattered all over the place, and I have definitely stumbled across useful stuff.  I feel that as there are clearly quite a few Linux Doomers, it might be useful to have a sub-forum dedicated to all things Linux/Doom? 

 

Or, does the forum have a concept of metadata tags for post classification? that could work too if these are searchable/filterable?

 

Just a thought...