search

ZDoom / gzdoom

GZDoom is a feature centric port for all Doom engine games, based on ZDoom, adding an OpenGL renderer and powerful scripting capabilities
http://zdoom.org
GNU General Public License v3.0
2.55k stars 552 forks source link

[BUG] AppImage fails to start on Fedora 38 #2203

Open jackrjli opened 1 year ago

jackrjli commented 1 year ago

GZDoom version

GZDoom 4.11.0 - Linux (AppImage) 64-bit

Which game are you running with GZDoom?

None

What Operating System are you using?

Linux x86_64

Please describe your specific OS version

Fedora 38

Relevant hardware info

No response

Have you checked that no other similar issue already exists?

A clear and concise description of what the bug is.

I tried running the GZDoom 4.11.0 AppImage on Fedora 38, and got the following error printed to the terminal:

/tmp/.mount_GZDoomVNc8cF/./gzdoom: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

I do have the shared library at /usr/lib64/libbz2.so.1.0.8 and the symlink /usr/lib64/libbz2.so.1 pointing to it, though I don't think that should matter for an AppImage.

Steps to reproduce the behaviour.

unzip GZDoom-v4.11.AppImage.zip
chmod u+x GZDoom-latest-x86_64.AppImage
./GZDoom-latest-x86_64.AppImage

Your configuration

No response

Provide a Log

No response

ghost commented 1 year ago

Can't say that the task is done for me. Still getting the same problem. I don't have any library shared or symlink pointing, but that sould not matter, does it?

My console promts:

/tmp/.mount_GZDoomSXmFwh/./gzdoom: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory

madame-rachelle commented 1 year ago

At the moment I have been completely unable to get the AppImage builder to include the extra files that are needed. Until this can be accomplished, this issue cannot be solved. The original PR came from @fang64 in the https://github.com/ZDoom/Raze repository and it eventually was migrated over to GZDoom.

I have been unable to get the AppImageBuilder to include the extra files needed, and given that Fedora is a frontline beta-testing OS, it simply is too much of a moving target this has not been the highest priority for me to address - which is not to say this issue isn't important or shouldn't be addressed - just that it takes too much time and resources to focus on.

ghost commented 1 year ago

This is completely understandable and I appreciate the immediate response very much. I hope that the future will lead us to a solution. Until then, I try to install the library with my basic Linux skills :-)

fang64 commented 1 year ago

Honestly have been busy with other projects, and haven't looked at this in awhile. Making things portable in App Image isn't difficult if using linuxdeploy to build the appimage since it chases down the libraries. However, be warned that compiler changes are painful. I just had this issue trying to resolve appimage dependencies for Bambu Studio/Orca Slicer @madame-rachelle . It seems that the transition to GCC 13 for some distributions causes hard seg faults with the libraries in the tree from older distros. So you can either target something pre GCC 13 or things afterward. Unless your application is portable enough to avoid what the distribution provides. @Bynbleidd I can take a look at this again and try to redo this with linuxdeploy when I get time.

smirnov commented 9 months ago

Encountered the same issue. From what I can find the issue is that fedora has the library under the name libbz2.so.1 not libbz2.so.1.0 If you want a quick and dirty fix - you can just apply cd /usr/lib64 && ln -s libbz2.so.1 libbz2.so.1.0 that should fix the most of it.