Official godot_x11 binaries can't locate libssl.so.1.0.0 on Fedora

[q2dg]

The error is:

./godot_x11-1.0stable.64: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

After doing ln -s /usr/lib64/libcrypto.so /usr/lib64/libcrypto.so.1.0.0 , I get this error:

./godot_x11-1.0stable.64: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

After doing ln -s /usr/lib64/libssl.so /usr/lib64/libssl.so.1.0.0 , I get this error:

./godot_x11-1.0stable.64: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./godot_x11-1.0stable.64)
./godot_x11-1.0stable.64: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./godot_x11-1.0stable.64)

I'm running a Fedora 21 system (64 bits, of course) with Openssl 1.0.1k installed (stock version from official repository)

[fry-]

I'm running Fedora21 (64bit) too and i experienced the same problems. I've built it (stable branch) from source, which works perfectly, so you could make it as a workaround until this issue gets fixed.

[q2dg]

Well, it seems to work. Thanks a lot!!

A request: could you add to "Requirements section" in https://github.com/okamstudio/godot/wiki/compiling_linux the command to install Fedora packages (as it is for Ubuntu)? I've successfully tried with:

dnf install scons python make automake gcc gcc-c++ kernel-devel pkgconfig libX11-devel libXcursor-devel alsa-lib-devel openssl-devel freetype-devel mesa-libGL-devel mesa-libGLU-devel pulseaudio-libs-devel

Only one thing: when I close the editor, I get in terminal these errors...I don't know if they are important:

ERROR: free: Method/Function Failed.
At: servers/visual/visual_server_raster.cpp:4314.
freed code id 6
ERROR: free: Method/Function Failed.
At: servers/visual/visual_server_raster.cpp:4314.
ERROR: free: Method/Function Failed.
At: servers/visual/visual_server_raster.cpp:4314.
ERROR: set_stream_peer: Condition ' p_peer.is_null() ' is true.
At: core/io/packet_peer.cpp:228.
base resources missing 2
ERROR: finish: Condition ' instance_dependency_map.size() ' is true.
At: servers/visual/visual_server_raster.cpp:7003.
ERROR: cleanup: ObjectDB Instances still exist!
At: core/object.cpp:1715.

[adolson]

For the record, this issue is still present nearly a year later for Fedora users (and possibly other distros). Debian (and I assume Ubuntu) have the same version of libssl as Fedora (1.0.1k) but they differ in file naming for whatever reason...

What this means is that if someone releases a game made with Godot, that game won't work for Fedora users. This is a problem. The Godot editor itself also won't work on Fedora, but can be made to work by compiling from source. This isn't possible with binary-released games.

There must be a better solution than requiring a specific version of libssl? Can it be linked to libssl.so instead? This is a symlink present on Fedora, Debian, Ubuntu, and likely other distros which points to the correct installed 1.0.1k libssl and I think it will solve the issue, at least partially... What happens when Fedora gets libssl.so.1.0.2 or something, and Godot is linked against libssl1.0.1? I have no idea... But for people looking to release games, this is something that needs to get addressed.

[germinolegrand]

same problem for me, my colleague built godot on ubuntu, can't run it on fedora.

[akien-mga]

There must be a better solution than requiring a specific version of libssl? Can it be linked to libssl.so instead? This is a symlink present on Fedora, Debian, Ubuntu, and likely other distros which points to the correct installed 1.0.1k libssl and I think it will solve the issue, at least partially...

Nope, libssl.so should not be present by default on new systems as it's a development library. It's likely provided by openssl-devel.
As far as I know it's a Fedora packaging bug as libssl clearly has 1.0.0 as a soname, even if its version is 1.0.2d on my system:

$ objdump -x /usr/lib64/libssl.so | grep SONAME
  SONAME               libssl.so.1.0.0

[akien-mga]

It seems that Fedora consider defines a custom SONAME for openssl, see the topic of this file: http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl.spec. As I know their packaging methods, I can imagine it was a useful change back then when they started doing it, and nowadays it's probably just obsolete nonsense. I guess we could try to make a bug report upstream to ask them to provide a libssl.so.1.0.0 symlink for libssl.so.10, but if we don't want to depend on them, we'd have to either:

• Hardcode a way to look for libssl.so.10 as a fallback if the libssl.so the engine was built against is not present (and bump this version when Fedora has a change of hearts). Edit: Actually it likely wouldn't work based on the first comment, even with symlinks there is still an issue.
• Link openssl statically, but I think that would be a bad idea as openssl is a very sensitive library with frequent security fixes, so linking a old version might mean linking against known vulnerabilities.
• Or don't enable openssl by default, so the issue would only affect users that really need the openssl functions.

[adolson]

There is a fourth solution: everyone stop using Fedora! :P

[akien-mga]

There is a fourth solution: everyone stop using Fedora! :P

Hehe. Better solution is likely to ask Fedora directly: https://bugzilla.redhat.com/show_bug.cgi?id=1277662

[q2dg]

@akien-mga 👍

[akien-mga]

So, it's likely a wontfix as far as Fedora is concerned, so we'll have to find a solution ourselves.

The simplest workaround would be to disable openssl support by default on X11 in https://github.com/godotengine/godot/blob/master/platform/x11/detect.py#L65. WDYT @reduz?