Note that some programs will dynamically load libraries at runtime, in addition to being linked against them at build time. These don’t necessarily show up in ldd. (Qt is horrible about this) Enabling core dumps or running under a debugger might shed some light on what’s going on. If that doesn’t work easily then check the project documentation to see if they have a special debugging workflow. Some game engines require a very specific debugging setup for the output to make any sense.
LMP From: Artur Tamm <artur.tamm...@gmail.com> Sent: Wednesday, December 14, 2022 1:13 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Gaming on gentoo Hi, I finally had the time to test quakespasm. I tried both the binary from the project as well as the version compiled by me from the project page on github. After copying the binary into quake folder (GoG version) and making symlinks to pak0.pak and pak1.pak (filesystem is case sensitive and the software cannot handle it). It worked fine. Artur Here is the ldd output (don't know if it helps) ldd quakespasm_compiled linux-vdso.so.1 (0x00007ffe3bd52000) libm.so.6 => /lib64/libm.so.6 (0x00007f2cd37c0000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f2cd373a000) libvorbisfile.so.3 => /usr/lib64/libvorbisfile.so.3 (0x00007f2cd3730000) libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007f2cd3702000) libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007f2cd36f7000) libmad.so.0 => /usr/lib64/libmad.so.0 (0x00007f2cd36d4000) libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x00007f2cd3668000) libc.so.6 => /lib64/libc.so.6 (0x00007f2cd346b000) /lib64/ld-linux-x86-64.so.2 (0x00007f2cd3db6000) libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f2cd33b3000) libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f2cd337f000) libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007f2cd328f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2cd328a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2cd3283000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f2cd313f000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f2cd3115000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f2cd3110000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f2cd3108000) libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007f2cd30ef000) libmd.so.0 => /usr/lib64/libmd.so.0 (0x00007f2cd30e1000) On Tue, 13 Dec 2022 at 14:24, Alan Ianson <agian...@gmail.com<mailto:agian...@gmail.com>> wrote: On Tue, 13 Dec 2022 13:49:54 +0000 Artur Tamm <artur.tamm...@gmail.com<mailto:artur.tamm...@gmail.com>> wrote: > sourceforge tarball was a prebuilt binary (at least the one I downloaded). The source is there too in a different directory. > I saw that the source code is here: > https://github.com/sezero/quakespasm/tree/master/Quake > The default Makefile might need some editing for a successful compilation. I just grabbed the linux-64 archive from sourceforge. I have never run the prebuilt binaries before but I tried it just to see what would happen. The quakespasm-sdl2 segfaulted the same as my own build but the quakespasm (sdl I suppose?) does run here. So that is something! I can run their sdl quakespasm but not my own built here. That is better than nothing but I'd still like to hear about your experience. I'd be happy if I could build and run my own if I can figure out what the issue is.
