I have downloaded the latest version of "Surviving Mars" from GOG.com and installed it, however no matter what I do, this game simply will NOT run... In fact, the game does not even try to run.

If I click the icon in the Applications View, nothing happens. If I try to force this game to launch with my dedicated graphics card (Applications View-->right-click on "Surviving Mars"-->Launch using Dedicated Graphics Card), nothing happens.

This was tested on two laptops:
* My old ASUS VivoBook X556UV laptop; and
* My new ASUS ZenBook Duo UX481 laptop.

I previously submitted a support ticket to Paradox Interactive about this, and they seemed to think that the GPU on my new laptop (the ZenBook Duo UX481) is unsuitable for "Surviving Mars" - but I did a bit of digging around it turns that that the GPU on my new laptop (the ZenBook Duo UX481) is actually slightly better than that of my old laptop (the VivoBook X556UV), both with regards to specifications and claimed performance... Furthermore, various other specifications are significantly better on my new laptop.

Yet my old laptop (the VivoBook X556UV) was previously able to run "Surviving Mars" flawlessly, whilst in fullscreen at its respective display's native resolution, prior to Ubuntu 20.04 LTS.

Both laptops had a "clean" install of Ubuntu 20.04 LTS and seeing as even my old laptop won't run "Surviving Mars" anymore, this to me suggests that the issue is related to Ubuntu 20,04 LTS itself...

When I try to start the game from Terminal, I am told:
./MarsGOG: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

I'm going to raise another support ticket with Paradox Interactive and GOG.com providing this new information, but any suggestions would be appreciated.

Just to get the ball rolling here, do you have the "libssl1.0.0" package installed?

If you're not already familiar, you may want to look into the "ldd" command to start tracking down required libs and their available paths.

These issues can go a number of ways, from simply having the right libs installed to setting LD_LIBRARY_PATH to wiping incompatible bundled libs. So, we'll just start at the beginning ;)

Since my original post, I did a quick search online and discovered that this error refers to OpenSSL... I also found a bug report that talks about why this was disabled in the first place:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736687

That bug report states in no uncertain terms that OpenSSL should not be installed unless absolutely necessary.

Members of another forum I frequent have stated that because this library is no longer supported due to security reasons, developers usually package this library with their game, so that it is only used by this game when it is running, rather than being installed and used system-wide... In the case of "Steam" games, this is achieved via the "Steam Runtime".

Other people have pointed out that most operating systems include an updated version of this library, and that "Surviving Mars" probably cannot "see" the updated version because it is expecting a lower version number... I checked, and this is in fact the case (I have a much newer version of this library already installed).

i have sent an e-mail to GOG.com asking about the possibility of them re-packaging "Surviving Mars" to include this library, or contacting Paradox Interactive and requesting that they do so...

I am still waiting on a reply, at the time of writing.

That's not what that bug report says at all. It says that the *default* cipher list is not secure and shouldn't be used (by developers). As an end-user, that has no direct bearing on you. That aside, over 100 security updates have been released on libssl1.0.0 since that particular bug report in 2014 (current version is 1.0.2n-1ubuntu5.3).

In other words, the library isn't insecure, it's how an inexperienced developer might utilize it that's in question (inappropriate defaults). Even if you presume game devs to know absolutely nothing about software security, precisely how concerned are you about the transmission encryption capabilities of Surviving Mars? ...It's not exactly banking software.

If you'd rather cling to healthy paranoia, though, there's libssl1.1 (1.1.1-1ubuntu2.1) as well, which isn't strictly API compliant, but you may have luck symlinking it to libssl.so.1.0.0 if the developer is only using a minor feature subset.

The 1.0.x branch has stuck around because so much older software (including many of the web servers you likely visit every day) are still based on the old API set, and, until they have time to update, it doesn't make sense to make the old library unavailable. It *is* secure (by modern business standards anyway) so long as developers manually select appropriate cipher sets in their code base.

Edit:
Extra side note -- when you say it was "disabled", I assume you mean not included in the latest LTS release (20.04), and in that respect, you're right. They can't and won't maintain dated software forever. Removing old packages lights a fire under developers' butts to get their crap updated and keep current ;)

If you need a copy of libssl1.0.0 specifically for Surviving Mars, even though it's not available for your distro, you can still download it directly and include it alongside the packaged game libraries.

Edit #2:
This issue was already addressed when Ubuntu 19.04 was released, here. To quote @Apaine directly: Of course, I'd recommend following the Ubuntu repo link I provided in the previous edit and downloading the most up-to-date version.

My point is not how concerned I am about my "Surviving Mars" data transmission, but the fact that this game does not work without this file being present, even if a newer version of said library is currently installed.

As previously stated, most game developers outside of Steam either include this library within the game files (so that it is only available to the game, whilst the game is running) or support the latest version (which does not have these security issues)... It's hard to say who is responsible because apparently GOG.com package some of the games they sell, but failing to include this library or better yet, support the updated version is not only lazy, but also game-breaking.

Your "everyday gamer" is not going to want to muck around trying to find out how to install unsupported libraries - they want to install the game and it "just works".

Seeing as "Surviving Mars" could not "see" the latest version of this library that I have installed, I was able to find a copy of this library in the game files for a "Steam" game, and then copy it to the "Surviving Mars" folder... It fixed the problem, but it's not a solution for most people and needs to be addressed by either GOG.com or Paradox Interactive.

So I am waiting to hear back from them, to see if one or the other is going to update this game to support the latest version or include this library...

Agreed, since the game lists support for "Ubuntu 14.04, 16.04 or newer," it should be updated to bundle required libs not available in 19.04 and 20.04 (or the system recommendations should be updated). Utilizing a newer, API-incompatible version of the library is not a packaging but a coding/compiling issue—the game or engine has to be updated to use the new API and the game must be recompiled against the new lib. That's not in GOG's purview. When packaging a game for Linux, developers always target a specific distribution (usually the current Ubuntu LTS) because of its default library set. Unlike in the Windows world, the Linux community typically frowns on application-specific library packaging, as it breaks the fundamental code-reuse policy on which much of the Linux ethos is based.

Developers are encouraged to keep their software up-to-date with the latest libraries, but it is—for better or worse—a system maintainer's responsibility to maintain legacy application support, and that includes knowing which libraries are required and keeping a copy of them around. Both Debian, Ubuntu, and OpenSuse make this about as easy as is possible with their online historical repositories.

Essentially, because Linux is built by and on a fragmented developer community, there is no "one source of truth" or an overarching corporate conglomerate with the monetary incentive to keep your games working. Sure, it's a double edged sword, but given the freedom and user-autonomy it provides, most of us prefer it that way.

As an aside, Steam comes bundled with a legacy library set, specifically for when developers don't bundle the required libs. TL;DR—Blame the game studio. If they don't believe they have the profit motive to maintain, they're offloading that responsibility to users.

A number of developers, myself included, do everything we can (within reason) to expand support for gaming on Linux. We realize a lack of software support was long an impediment to user adoption—and we like to play games too ;)

Your "everyday gamer" is a Windows user—so countless hours have been spent on the Wine project to create a bridge between otherwise incompatible binaries. Last I checked, I believe Steam play supported well over 7000 Windows titles via Proton (Wine). So I'd say we've made a lot of strides over the last couple decades, and game studios are starting to take notice of the growing Linux market. But their past release and maintenance experience is very different. There will certainly be an adjustment period and some growing pains.

I'm not about to pretend that the core Linux ethos does (or ever will) mesh with a "just works" mentality. Not that we don't want that (we do!), but it's the job of both the software developers and the individual users to build and maintain that support network. Projects like Winetricks, Steam's Proton, CodeWeavers CrossOver, PlayOnLinux, and Lutris attempt to play middle-man to fill that role for Windows-exclusive titles, but native Linux applications have to work the Linux way (or change what that way is).

At the end of the day, it's avoiding throwing in the kitchen sink with both the operating system and every application that keeps the bloat down and keeps Linux performing better than its peers. I'd really recommend downloading an updated version instead of pulling an unknown version from a rival developer. But hey, it's your system. As I mentioned, Steam also maintains a legacy library set, so that might contain a maintained version if you would rather avoid the Ubuntu repo for some reason. As I understand it—with the developer's permission, GOG could probably bundle libssl.so.1.0.0. Anymore requires developer support.

In the mean time, join the rest of us in supporting things from the user end :)

I was able to get this game working on Ubuntu 20.04 following the instructions posted by xixas.

Now the game seems to work but the pause screen renders as a difficult to read pink (screenshot attached).

I did most of this from the command line but will make these instructions as GUI friendly as possible.

1) Download from: security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/

libssl1.0.0_1.0.2n-1ubuntu5.3_amd64.deb or similar

2) Once downloaded, open if in the Files GUI and double click

3) Click Extract and extract the files to a directory such as Desktop

4) Double-click the data.tar.gz file and extract to a directory (or tar xvf data.tar.gz).

5) Navigate within the newly created subdirectory to./usr/lib/x86_64-linux-gnu/

6) Copy libssl.so.1.0.0 and libssl.so.1.0.0 to GOG Games/Surviving Mars/game under your home directory

The game should now launch and seems to work except for the pink pause screen issue.

Edit: I think much of this confusion can be avoided by packaging the above two library files in the installed directory.

Thanks, that worked out of the box! I can confirm this pink/buggy background issue.

Sorry to necro this very old thread, but libssl version 1.0 has not shipped for years now and that was the case back in 2020 as well.

You write a nice essay on updating and familiarity... but really? libssl1 should not be used, it is not present and has not been present on modern systems for years now (deprecated since at least 2016 also for 18.04).

The developer would have to statically link it instead of expecting customers to run outdated software.

If you want these ancient libraries, you have to fish them out of the steam runtime folder for ubuntu12.

Thanks for the time-saving tip, I was trying to run via Heroic and learned the same lesson.

And that is why I do not load the linux versions from GOG any longer but use the windows versions instead. There is not one single linux game on GOG that I managed to get running properly. Whereas the windows versions always work using wine/proton.

I think GOG should do more for linux gaming or just offer the windows versions only. Otherwise a lot of people waste a lot of time just to find out that it does not work.

That is simply not how you treat customers.

PS: It must be possible to make this a lot easier. I e. g. have an almost 15 years old deb-file of the game Osmos and that file still installs without any trouble on every recent debian based linux distro I have tried.