It seems an Arch update today has broken a few games, several Feral Interactive titles as well as Civilization VI from Aspyr Media no longer run.
It's apparently an issue with the Arch update of openssl. I sadly updated without knowing it was an issue, so certain games are now broken for me. I've had this confirmed by multiple other reports, so it's certainly not me. There's also a bug report open for it.
Titles I've personally tested that no longer load:
Here's an example of what happens when XCOM 2 won't launch now:
This is just a PSA to highlight the issue. Feel free to share any helpful tips in the comments.
Plenty of games do still work though, it does not affect all games.
Update: A workaround is to install libopenssl-1.0-compat and use that for the games that don't work.
You can then add this to the launch options of the games that don't work:
Another workaround is to re-install an earlier version by doing:
Downgrading isn't always advisable, I tested both methods and both work. Installing the AUR package is probably the better solution.
It's apparently an issue with the Arch update of openssl. I sadly updated without knowing it was an issue, so certain games are now broken for me. I've had this confirmed by multiple other reports, so it's certainly not me. There's also a bug report open for it.
Titles I've personally tested that no longer load:
- DiRT Rally
- HITMAN
- Dawn of War II
- XCOM 2
- Civilization VI
- Probably others too
Here's an example of what happens when XCOM 2 won't launch now:
Quote/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2)
/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/libldap_r-2.4.so.2: no version information available (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/../lib/x86_64/libcurl.so.4)
/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/liblber-2.4.so.2: no version information available (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/../lib/x86_64/libcurl.so.4)
/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/../lib/x86_64/libcurl.so.4)
/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/../lib/x86_64/libcurl.so.4)
/mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/XCOM2: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /mnt/storage/SteamLibrary/steamapps/common/XCOM 2/bin/../lib/x86_64/libcurl.so.4)
This is just a PSA to highlight the issue. Feel free to share any helpful tips in the comments.
Plenty of games do still work though, it does not affect all games.
Update: A workaround is to install libopenssl-1.0-compat and use that for the games that don't work.
You can then add this to the launch options of the games that don't work:
LD_LIBRARY_PATH=/usr/lib/openssl-1.0-compat/ %command%
Another workaround is to re-install an earlier version by doing:
pacman -U https://archive.archlinux.org/packages/o/openssl-1.0/openssl-1.0-1.0.2.k-2-x86_64.pkg.tar.xz
Downgrading isn't always advisable, I tested both methods and both work. Installing the AUR package is probably the better solution.
Some you may have missed, popular articles from the last month:
Wow, so much bad advice in such a short amount of time!
Don't symlink the new soname to masquerade it as the old soname. Don't downgrade your openssl package, you'll break everything that now depends on the new soname (including pacman! Well done!). STiAT had the closest to the correct solution, but [never "-Sy" anything](https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported).
See https://bugs.archlinux.org/task/53618, particularly Christoph Haag's comment.
Don't symlink the new soname to masquerade it as the old soname. Don't downgrade your openssl package, you'll break everything that now depends on the new soname (including pacman! Well done!). STiAT had the closest to the correct solution, but [never "-Sy" anything](https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported).
See https://bugs.archlinux.org/task/53618, particularly Christoph Haag's comment.
6 Likes, Who?
I was suffering this issue since Superposition came out as I was one of the few that wasn't able to run it (I have the testing repos enabled).
There is an easy fix: install libopenssl-1.0-compat from the AUR and then load that specific library
LD_LIBRARY_PATH=/usr/lib/openssl-1.0-compat/
Now I'm able to run Superposition (at 10fps lol)
ps. mind that there is a key to import, check the aur page for more info
There is an easy fix: install libopenssl-1.0-compat from the AUR and then load that specific library
LD_LIBRARY_PATH=/usr/lib/openssl-1.0-compat/
Now I'm able to run Superposition (at 10fps lol)
ps. mind that there is a key to import, check the aur page for more info
3 Likes, Who?
Quoting: WorMzyDon't downgrade your openssl package, you'll break everything that now depends on the new soname (including pacman! Well done!).
Not true in this instance. openssl is at its latest version on my system (1.1.0.e-1) and I only downgraded openssl-1.0 to 1.0.2.k-2. No breakage to either pacman or anything else insofar I can tell. This is after rebooting and explicitly checking if I could still install, sync and whatever else with pacman after downgrading. And things like Mad Max and Civ 6 work. You may be right in general about downgrading packages but this is a simple workaround if you're too impatient to wait until they fix this.
0 Likes
Quoting: GuestLaunching Steam with this doesn't resolve it?No.
STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0
0 Likes
Thanks for the heads up Liam
0 Likes
Situations like this is one of the several reasons why I don't use Arch for gaming. With Arch, it's always something.
2 Likes, Who?
Quoting: BTREQuoting: WorMzyDon't downgrade your openssl package, you'll break everything that now depends on the new soname (including pacman! Well done!).
Not true in this instance. openssl is at its latest version on my system (1.1.0.e-1) and I only downgraded openssl-1.0 to 1.0.2.k-2. No breakage to either pacman or anything else insofar I can tell.
I'm not sure how you managed this. Curl has been rebuilt against openssl 1.1.0.e-1 (libssl.so.1.1.0), removing it (by downgrading openssl) will cause pacman to break with "error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory".
Downgrading is not a solution, and just downgrading one package amounts to a partial upgrade.
0 Likes
Quoting: WorMzyQuoting: BTREQuoting: WorMzyDon't downgrade your openssl package, you'll break everything that now depends on the new soname (including pacman! Well done!).
Not true in this instance. openssl is at its latest version on my system (1.1.0.e-1) and I only downgraded openssl-1.0 to 1.0.2.k-2. No breakage to either pacman or anything else insofar I can tell.
I'm not sure how you managed this. Curl has been rebuilt against openssl 1.1.0.e-1 (libssl.so.1.1.0), removing it (by downgrading openssl) will cause pacman to break with "error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory".
Downgrading is not a solution, and just downgrading one package amounts to a partial upgrade.
you have core/openssl 1.1.0.e-1 [installed] and extra/openssl-1.0 1.0.2.k-3 [installed]
he talks about downgrading 1.0.2.k not 1.1.0.e
0 Likes
Quoting: WorMzyI'm not sure how you managed this. Curl has been rebuilt against openssl 1.1.0.e-1 (libssl.so.1.1.0), removing it (by downgrading openssl) will cause pacman to break with "error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory".
Downgrading is not a solution, and just downgrading one package amounts to a partial upgrade.
libssl.so.1.1 is provided by the package openssl (in Core) as is libcrypto.so and libcrypto.so.1.1. Most of the things pointed out by you depend on these libraries.
These games, on the other hand, depend on libraries from another package entirely. openssl-1.0 (in Extra), which provides things like libcrpyto.so.1.0.0 and libssl.so.1.0.0. They're not the same thing and I think that this is where our misunderstanding is coming from.
Though yeah, I will concede that downgrading packages is not much of a solution and has its risks. And people should generally not be encouraged to do so blindly. Which is why I suggested that Liam add a disclaimer. But in this case, I still haven't had any errors of any sort.
1 Likes, Who?
Ahh, yeah, my bad. I totally misread. Downgrading openssl-1.0 is definitely not as big a deal as downgrading openssl (which is what I thought we were talking about). Sorry BTRE.
1 Likes, Who?
See more from me