ferallinuxscripts
ferallinuxscripts copied to clipboard
FeralInteractive
DiRT Rally fails to Launch [Arch][Tumbleweed]
Having an issue with Dirt Rally, It worked fine few days ago. Now im getting this:
/mnt/SSDGames/SteamLibrary/steamapps/common/DiRT Rally/bin/DirtRally: error while loading shared libraries: libSDL2-2.0.5.so: cannot open shared object file: No such file or directory
'DiRT Rally' quit with error code '127'.
If possible, launch Steam from command line to check the output when 'DiRT Rally' is run.
Then, contact [email protected] with details of the output, as well as your Steam System Info.
GameAction [AppID 310560, ActionID 2] : LaunchApp changed task to Completed with ""
>>> Adding process 2902 for game ID 310560
>>> Adding process 2904 for game ID 310560
>>> Adding process 2911 for game ID 310560
>>> Adding process 2917 for game ID 310560
>>> Adding process 2918 for game ID 310560
Generating new string page texture 370: 256x256, total string texture memory is 3.96 MB
Game removed: AppID 310560 "DiRT Rally", ProcID 2901
shadercachemanager/shadercacheimplnvidia.cpp (112) : Assertion Failed: App 310560 has more than one NVIDIA disk cache instance!
Assert( Assertion Failed: App 310560 has more than one NVIDIA disk cache instance! ):shadercachemanager/shadercacheimplnvidia.cpp:112
Installing breakpad exception handler for appid(steam)/version(1502839813)
crash_20170820192627_25.dmp[2947]: Uploading dump (out-of-process)
/tmp/dumps/crash_20170820192627_25.dmp
System info:
Computer Information: Manufacturer: Unknown Model: Unknown Form Factor: Desktop No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 1700X Eight-Core Processor
CPU Family: 0x17
CPU Model: 0x1
CPU Stepping: 0x1
CPU Type: 0x0
Speed: 3900 Mhz
16 logical processors
8 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version: "Arch Linux" (64 bit) Kernel Name: Linux Kernel Version: 4.12.1-2-hz X Server Vendor: The X.Org Foundation X Server Release: 11903000 X Window Manager: Metacity (Marco) Steam Runtime Version: steam-runtime-beta-release_2017-07-24
Video Card: Driver: NVIDIA Corporation GeForce GTX 1070/PCIe/SSE2 Driver Version: 4.5.0 NVIDIA 384.59 OpenGL Version: 4.5 Desktop Color Depth: 24 bits per pixel Monitor Refresh Rate: 119 Hz VendorID: 0x10de DeviceID: 0x1b81 Revision Not Detected Number of Monitors: 2 Number of Logical Video Cards: 1 Primary Display Resolution: 2560 x 1440 Desktop Resolution: 4480 x 1440 Primary Display Size: 23.50" x 13.23" (26.97" diag) 59.7cm x 33.6cm (68.5cm diag) Primary Bus: PCI Express 16x Primary VRAM: 8192 MB Supported MSAA Modes: 2x 4x 8x 16x
Sound card: Audio device: Nvidia GPU 83 HDMI/DP
Memory: RAM: 32175 Mb
Miscellaneous: UI Language: English LANG: en_US.UTF-8 Total Hard Disk Space Available: 2815659 Mb Largest Free Hard Disk Block: 352451 Mb VR Headset: None detected
Recent Failure Reports:
What i have tried to fix this problem so far?
- Verified Game files
- Tried launching Steam stable version as well as beta version with and without native runtime.
- Tried to delete Nvidia's GL Cache from $HOME/.nv/GLCache
Still same problems
Ok it seems its the SDL2 issue.. i wonder why it cannot open that file, its bundled with the Dirt Rally and i see it in the folder there.
Update.
Seems all feral games have this issue. i mean every game reports different missing .so file but i tested: Hitman, Mad Max, F1 2015, Alien Isolation... all have similar crash and just different .so file is reported to be missing, though i see those files bundled with the game..
Other non-feral games seem to be not having this issue.. is there something wrong with the paths on my system?
Ok, fixed it with a workaround. added this to the steam launch options
LD_LIBRARY_PATH="/home/xpander/Games/Steam/steamapps/common/DiRT Rally/lib/x86_64/" %command%
now it works. But why doesnt it work like that by default is beyond me
Hi @xpander69, cheers for the report and workaround.
So our games find those libraries by using the ELF RPATH attribute, you can see this here:
$ objdump -x bin/DirtRally | grep RPATH
RPATH $ORIGIN/../lib
This means even a raw ldd outside the steam runtime should find them, like so
$ ldd bin/DirtRally | grep SDL2-2
libSDL2-2.0.5.so => /opt/steam/steamapps/common/DiRT Rally/bin/../lib/x86_64/libSDL2-2.0.5.so (0x00007f8d2e52b000)
Unfortunately, I'm testing this on Arch updated this morning and our steam games are running fine, so I'm unsure what the issue is on your end, could you share the output of the above commands?
yeah seems to be my system then.
xpander@arch /mnt/stuff/xpander/Games/Steam/steamapps/common/DiRT Rally/bin $ ldd DirtRally | grep SDL2-2
libSDL2-2.0.5.so => not found
i have no idea why though. have to investigate. i do use testing repos of arch though, maybe something is screwed up there.
full ldd -r log
https://pastebin.com/jMP8Vjxc
Thanks for looking into it further.
Let me know if you find anything out - issues like these can be early warning signs of future breakages on more stable repos.
Hi, no i did not :( someone in GOL forum said that he have had this issue also in the past.
Worth noting this also appears to be happening in raw Tumbleweed installations
@xpander69 to get you gaming now, it looks like a workaround is to move the contents of DiRT Rally/lib/x86_64/ into DiRT Rally/lib/. It appears something about ld's automatic addition of the $PLATFORM variable to RPATH isn't working quite as expected.
Thanks. Confirming it works that way.
i added symlinks to DiRT Rally/lib/
Cheers, could you also run this command and paste the output?
LD_DEBUG=libs ldd bin/DirtRally
Much appreciated, I'll clean up the back and forth from the thread.
Looks like some change in the fundamentals of ld or maybe libc has changed how search path there is generated. On working setups search path would contain lib/x86_64, on your setup you end up with only the base lib path, and on my Tumbleweed case I have haswell instead of x86_64.
How strange, will investigate more. For now as you've confirmed this will fix it:
cd '/path/to/DiRT Rally/'
ln -s lib/x86_64/* lib/
I've reported the issue we see here on the openSUSE bugzilla while we investigate. Perhaps someone knows what was changed.
If you're feeling particularly inclined to do the same for Arch then go ahead. Unfortunately I can't make the report as I still can't reproduce the issue on my Arch installations.
Not sure how helpful I can be, but I recently encountered this problem on Arch w/ [testing] and Life Is Strange.
Making links in Life Is Strange/lib/ doesn't do it, but the command line parameters work for me:
LD_LIBRARY_PATH="/data/padster/Games/Steam/steamapps/common/Life Is Strange/lib/x86_64/" %command%
Also needed to install librtmp0, which I didn't have before and it used to work fine, oddly enough.
Did a pastebin of LD_DEBUG=libs ldd bin/LifeIsStrange as well.
Cheers, @theRealPadster that certainly looks like the same issue, you're getting the haswell inclusion issue I see on Tumbleweed.
Not sure about librtmp0 needing to be installed, but your workaround is also a valid one.
LD_LIBRARY_PATH="/path/to/steam/games/steamapps/common/gamename/lib/x86_64/" %command%
Looks like this might be a glib ABI breakage from this commit.
I've added that to the SUSE bug report as glibc's conduct states to report to distribution maintainers before going directly to GNU. Hopefully, this will get looked into soon.
I'm now seeing this with Arch. Downgrading glibc rectifies the problem. So it's pretty much confirmed.
I had the same issue on Slackware64 -current. Fixed it by moving lib dir (per game) as noted above.
This was also reported on the Arch Linux bugtracker: https://bugs.archlinux.org/task/55563
We've now backported the patch from https://sourceware.org/bugzilla/show_bug.cgi?id=22093 so Arch users should do a full system update to get glibc 2.26-4
Still does the same thing (just not launch) with glibc 2.26-4 if I remove the launch options.
Hi all,
I can confirm that 2.26-4 works fine without the launch options. Just tested it.
On Thu, Sep 14, 2017 at 11:21 PM, Isaac [email protected] wrote:
Still does the same thing (just not launch) with glibc 2.26-4 if I remove the launch options.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FeralInteractive/ferallinuxscripts/issues/3#issuecomment-329516554, or mute the thread https://github.com/notifications/unsubscribe-auth/AXv4KsbwdEUqTaMjC7QgmoJiXB4xB-59ks5siUR5gaJpZM4O-82I .
Then why isn't it working for me? o.0
[padster@noctus ~]$ pacman -Ss glibc | grep installed
core/glibc 2.26-4 (base) [installed]
multilib/lib32-glibc 2.26-2 [installed]
Steam output here Could be this?
/data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/LifeIsStrange: /usr/lib/libldap_r-2.4.so.2: no version information available (required by /data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/../lib/x86_64/libcurl.so.4)
/data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/LifeIsStrange: /usr/lib/liblber-2.4.so.2: no version information available (required by /data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/../lib/x86_64/libcurl.so.4)
Hi,
Life is Strange works fine too. I just tested all of the games.
On 14 Sep 2017 23:45, "Isaac" [email protected] wrote:
Then why isn't it working for me? o.0
[padster@noctus ~]$ pacman -Ss glibc | grep installed core/glibc 2.26-4 (base) [installed] multilib/lib32-glibc 2.26-2 [installed]
Steam output here https://pastebin.com/M1JU6YJe Could be this?
/data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/LifeIsStrange: /usr/lib/libldap_r-2.4.so.2: no version information available (required by /data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/../lib/x86_64/libcurl.so.4) /data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/LifeIsStrange: /usr/lib/liblber-2.4.so.2: no version information available (required by /data/padster/Games/Steam/steamapps/common/Life Is Strange/bin/../lib/x86_64/libcurl.so.4)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FeralInteractive/ferallinuxscripts/issues/3#issuecomment-329524041, or mute the thread https://github.com/notifications/unsubscribe-auth/AXv4KjMkcU94_QA5V4G_O78qhjU6IFA2ks5siUoRgaJpZM4O-82I .
Thanks all,
Some quick housekeeping:
@theRealPadster your issue is likely issue 2 which is currently being fixed. @eli-schwartz glad it's fixed on Arch, much appreciated. @Cxpher thanks for verifying.
Looks like this is resolved on most affected systems, but I'll keep the bug open for a while longer just in case it shows up elsewhere.
All Feral games I have on Steam stopped working for me a few days ago on Ubuntu 17.10. Not sure if related to the previous issues in this thread.
kristoffer@kristoffer-ubuntu-desktop:~/.steam/steam/steamapps/common/ShadowOfMordor/bin$ ./ShadowOfMordor
./ShadowOfMordor: error while loading shared libraries: libicui18n.so.51: cannot open shared object file: No such file or directory
kristoffer@kristoffer-ubuntu-desktop:~/.steam/steam/steamapps/common/ShadowOfMordor/bin$ steam
Running Steam on ubuntu 17.10 64-bit
STEAM_RUNTIME is enabled automatically
Pins up-to-date!
[2017-09-22 12:53:14] Startup - updater built Sep 6 2017 20:37:15
[2017-09-22 12:53:14] Verifierar installation...
[2017-09-22 12:53:14] Verification complete
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
=== ERROR - You're missing vital libraries to run Middle Earth Shadow of Mordor
=== Either use the steam runtime or install these using your package manager
libSDL2_image-2.0.so.0 => not found
librtmp.so.0 => not found
===
Cheers @Brisse89, looks like the 17.10 beta doesn't have the needed fix, I'll investigate where to report this on their end
@mdiluz It should be fixed upstream. Otherwise every single distro out there will have this issue. That or Feral need to change their logic for detecting lib path.
@sbolokanov yup, it's been fixed upstream here.
Unfortunately that means it won't make it into a main tag until glibc-2.27, and 17.10 may launch with a version that doesn't get have the fix.
I've reported this to Canonical here now, so hopefully this will get resolved soon.
In the meantime, using LD_PRELOAD as a workaround should get the games running for you.