When ever I try to run ut2004, I get the following: ./ut2004-bin: /usr/lib64/libstdc++.so.5: no version information available (required by ./ut2004-bin) ./ut2004-bin: /usr/lib64/libstdc++.so.5: no version information available (required by ./ut2004-bin) Signal: SIGSEGV [segmentation fault] Aborting. Crash information will be saved to your logfile. I looked into it more and I know it has to do with sound because when I disable sound, the game will come up. I've attached an strace log and "emerge --info". Reproducible: Always Steps to Reproduce: 1. Start game. 2. Game segfaults. Actual Results: The steps to reproduce show the issue. Expected Results: Game to run with sound.
Created attachment 896425 [details] emerge --info
for the record, which version is installed? (yes I realize the repo has only one today, but just so the info is available)
Created attachment 896426 [details] strace part 0
Created attachment 896427 [details] strace part 1
(In reply to Greg Kubaryk from comment #2) > for the record, which version is installed? (yes I realize the repo has only > one today, but just so the info is available) Sorry about that. I've updated the summary line with 3369.3-r3.
FWIW, I just updated my system, and it still works fine with sound here. The game uses OpenAL. Try games-arcade/supertux as a comparison, that uses OpenAL too.
Just a gut feeling, but what does the output from `openal-info` look like (the top section especially), and do you have a custom $XDG_CONFIG_DIR/alsoft.conf? I'm wondering if something is going on here like in Mesa, where the opengl extension list got so long in 4.x it started buffer overrunning old games. Sound card strings might be another way to cause that, and I'm not seeing many other possibilities. Nothing obvious jumps out from a diff of the strace to mine (working). I see yours is loading libpulse-simple while my openal only has USE=pipewire, but I don't want to claim it's that without knowing more first.
(In reply to James Le Cuirot from comment #6) > FWIW, I just updated my system, and it still works fine with sound here. The > game uses OpenAL. Try games-arcade/supertux as a comparison, that uses > OpenAL too. I have several games that rely on OpenAL: # emerge -cpv openal Calculating dependencies... done! media-libs/openal-1.23.1-r1 pulled in by: games-fps/dhewm3-1.5.2 requires media-libs/openal games-fps/quake3-9999 requires media-libs/openal games-fps/ut2004-3369.3-r3 requires media-libs/openal games-fps/yamagi-quake2-8.30 requires media-libs/openal >>> No packages selected for removal by depclean None of them have an issue with sound with the exception of ut2004. So after looking into what supertux requires specific to OpenAL and libsdl2, it's not different from others I have installed depending on OpenAL. And ut2004 is the only one that depends on libsdl. All others depend on libsdl2. (In reply to Enne Eziarc from comment #7) > Just a gut feeling, but what does the output from `openal-info` look like > (the top section especially), and do you have a custom > $XDG_CONFIG_DIR/alsoft.conf? > > I'm wondering if something is going on here like in Mesa, where the opengl > extension list got so long in 4.x it started buffer overrunning old games. > Sound card strings might be another way to cause that, and I'm not seeing > many other possibilities. > > Nothing obvious jumps out from a diff of the strace to mine (working). I see > yours is loading libpulse-simple while my openal only has USE=pipewire, but > I don't want to claim it's that without knowing more first. Here's the output from "openal-info": Available playback devices: Starship/Matisse HD Audio Controller Analog Stereo Available capture devices: Monitor of Starship/Matisse HD Audio Controller Analog Stereo Default playback device: Starship/Matisse HD Audio Controller Analog Stereo Default capture device: Monitor of Starship/Matisse HD Audio Controller Analog Stereo ALC version: 1.1 ** Info for device "Starship/Matisse HD Audio Controller Analog Stereo" ** ALC version: 1.1 ALC extensions: ALC_ENUMERATE_ALL_EXT, ALC_ENUMERATION_EXT, ALC_EXT_CAPTURE, ALC_EXT_DEDICATED, ALC_EXT_disconnect, ALC_EXT_EFX, ALC_EXT_thread_local_context, ALC_SOFT_device_clock, ALC_SOFT_HRTF, ALC_SOFT_loopback, ALC_SOFT_loopback_bformat, ALC_SOFT_output_limiter, ALC_SOFT_output_mode, ALC_SOFT_pause_device, ALC_SOFT_reopen_device Available HRTFs: Default HRTF Built-In HRTF Device output mode: Stereo (basic) Device sample rate: 48000hz OpenAL vendor string: OpenAL Community OpenAL renderer string: OpenAL Soft OpenAL version string: 1.1 ALSOFT 1.23.1 OpenAL extensions: AL_EXT_ALAW, AL_EXT_BFORMAT, AL_EXT_DOUBLE, AL_EXT_EXPONENT_DISTANCE, AL_EXT_FLOAT32, AL_EXT_IMA4, AL_EXT_LINEAR_DISTANCE, AL_EXT_MCFORMATS, AL_EXT_MULAW, AL_EXT_MULAW_BFORMAT, AL_EXT_MULAW_MCFORMATS, AL_EXT_OFFSET, AL_EXT_source_distance_model, AL_EXT_SOURCE_RADIUS, AL_EXT_STATIC_BUFFER, AL_EXT_STEREO_ANGLES, AL_LOKI_quadriphonic, AL_SOFT_bformat_ex, AL_SOFTX_bformat_hoa, AL_SOFT_block_alignment, AL_SOFT_buffer_length_query, AL_SOFT_callback_buffer, AL_SOFTX_convolution_reverb, AL_SOFT_deferred_updates, AL_SOFT_direct_channels, AL_SOFT_direct_channels_remix, AL_SOFT_effect_target, AL_SOFT_events, AL_SOFT_gain_clamp_ex, AL_SOFTX_hold_on_disconnect, AL_SOFT_loop_points, AL_SOFTX_map_buffer, AL_SOFT_MSADPCM, AL_SOFT_source_latency, AL_SOFT_source_length, AL_SOFT_source_resampler, AL_SOFT_source_spatialize, AL_SOFT_source_start_delay, AL_SOFT_UHJ, AL_SOFT_UHJ_ex Available resamplers: Nearest Linear Cubic * 11th order Sinc (fast) 11th order Sinc 23rd order Sinc (fast) 23rd order Sinc EFX version: 1.0 Max auxiliary sends: 2 Supported filters: Low-pass, High-pass, Band-pass Supported effects: EAX Reverb, Reverb, Chorus, Distortion, Echo, Flanger, Frequency Shifter, Vocal Morpher, Pitch Shifter, Ring Modulator, Autowah, Compressor, Equalizer, Dedicated Dialog, Dedicated LFE And it looks like $XDG_CONFIG_DIR is not set: $ echo $XDG_CONFIG_DIR $ There is one under $HOME/.config, however after moving that out of the way, it's the same issue with the same output. ---------- Okay, so here's some more background as I feel it's needed and honestly should have included with the original report: I actually installed this game back in February of 2021 and everything worked with no issues. However this issue actually started some time ago, probably over a year by now. As I don't play this game often, I can't tell you the exact update that caused this issue. I did check the forums and bug reports to see if anyone reported anything from time to time on my issue, but it never was so I submitted this one. As no reports of this came up, I felt that I was unique here. I have tried the previous version of OpenAL, different version of libsdl, and various USE flags to no avail. I've tried different settings for OpenAL with no change. The only thing that gets the game to play is by disabling audio. For libsdl specifically, I have kept it to version 1.2.15_p20221201 specifically as the libsdl compat versions cause issues for me. Mouse tracking, jitter in the graphics, and the video card sounds like it's about to take off. But even if I upgrade to one of the newer versions, it still has the same issue. If there is anything you need me to test or try, just let me know. I don't play the game often, but I would like to play it.
The one thing that stands out for me is that you're on a hardened profile, but if it used to work, it's hard to see how that could be the issue. You have the pulseaudio and pipewire USE flags on, so presumably you're using pipewire, but it sounds like you've tried using the pulseaudio driver too. I actually tried playing the game just now, and the graphics did seem a bit jittery in a way they weren't previously. Maybe it's sdl12-compat, but I tried turning adaptive sync off, and I think that helped.
(In reply to James Le Cuirot from comment #9) > The one thing that stands out for me is that you're on a hardened profile, > but if it used to work, it's hard to see how that could be the issue. > > You have the pulseaudio and pipewire USE flags on, so presumably you're > using pipewire, but it sounds like you've tried using the pulseaudio driver > too. > > I actually tried playing the game just now, and the graphics did seem a bit > jittery in a way they weren't previously. Maybe it's sdl12-compat, but I > tried turning adaptive sync off, and I think that helped. Sorry for the late reply, but here we are... Anyway, at one time my system was using pulseaudio for sound but then I switched to pipewire. However, I was using pipewire for awhile well before this problem had arisen. As for sdl12-compat, I've run it under libsdl12 and sdl12-compat as stated previously. And this was before the problem existed as well. For new fun, I decided to use DDD to see if anything would be reported and and this is what came up: gdb) file /opt/ut2004/System/ut2004-bin Reading symbols from /opt/ut2004/System/ut2004-bin... (No debugging symbols found in /opt/ut2004/System/ut2004-bin) (gdb) set args (gdb) run Starting program: /opt/ut2004/System/ut2004-bin /opt/ut2004/System/ut2004-bin: /usr/lib64/libstdc++.so.5: no version information available (required by /opt/ut2004/System/ut2004-bin) /opt/ut2004/System/ut2004-bin: /usr/lib64/libstdc++.so.5: no version information available (required by /opt/ut2004/System/ut2004-bin) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffedbff6c0 (LWP 15577)] [New Thread 0x7fffed2bd6c0 (LWP 15578)] [New Thread 0x7fffecabc6c0 (LWP 15579)] [New Thread 0x7fffdffff6c0 (LWP 15580)] [New Thread 0x7fffdf5fe6c0 (LWP 15581)] [New Thread 0x7fffdedfd6c0 (LWP 15582)] [New Thread 0x7fffde5fc6c0 (LWP 15583)] [New Thread 0x7fffdddfb6c0 (LWP 15584)] [New Thread 0x7fffdd5fa6c0 (LWP 15585)] [Thread 0x7fffdd5fa6c0 (LWP 15585) exited] [Thread 0x7fffdddfb6c0 (LWP 15584) exited] [Thread 0x7fffde5fc6c0 (LWP 15583) exited] [New Thread 0x7fffde5fc6c0 (LWP 15586)] [New Thread 0x7fffdddfb6c0 (LWP 15587)] [New Thread 0x7fffdd5fa6c0 (LWP 15588)] Thread 1 "ut2004-bin" received signal SIGSEGV, Segmentation fault. 0x00007ffff7ee5067 in std::locale::operator=(std::locale const&) () from /usr/lib64/libstdc++.so.5 It starts the binary and this is all that it shows. So I believe the issue is with libstdc++-v3, which I'm running version 3.3.6-r4, but this is as far as I can get as I'm not used to debugging running programs. If anyone has any suggestions for me to try, it would be appreciated.
I haven't rebuilt libstdc++-v3 since 2021, so I'll try to do that to see whether it changes anything. It's not building at all here right now though, so I'll need to fix that first.
Someone fixed libstdc++-v3 for me. I rebuilt it, and I'm sorry to say that it all still works here. You could try building it again to see if the new flag handling helps.
