Arch Linux

There is no concept of "wrong" symbol versions, by default openssl-1.0 symbols are not versioned so every distro is using their own versioning. We are actually using Debian's patch from Stretch, yours is from Jessie. So even Debian is not keeping compatibility between versions.
This patch would fix some stuff now, but as soon as closed source developers start compiling their stuff against Stretch it will break again. In  FS#53618  there is another, more future-proof solution proposed.

> There is no concept of "wrong" symbol versions, by default openssl-1.0 symbols are not versioned so every distro is using their own versioning.

So? A distro can do wrong versioning, and Arch Linux is doing so. SSL_CTX_new is found in 1.0.0.

> We are actually using Debian's patch from Stretch, yours is from Jessie.

The version of openssl in Stretch is 1.1.0e, and has no versioning symbols patch. So what are you talking about?

> This patch would fix some stuff now, but as soon as closed source developers start compiling their stuff against Stretch it will break again.

No it won't. SSL_CTX_new@@OPENSSL_1.0.0 will *always* be SSL_CTX_new@@OPENSSL_1.0.0, because that is the correct version. If a program is compiled against SSL_CTX_new@@OPENSSL_1.0.2d by *mistake*, then supposedly only a warning will appear.

Debian has the versioning right.

> The version of openssl in Stretch is 1.1.0e, and has no versioning symbols patch. So what are you talking about?

I am talking about this https://packages.debian.org/stretch/libssl1.0-dev

Tried the patch with Shadow of Mordor and it works fine

Debian has multiple versions of OpenSSL:
- libssl1.0.0: libssl.so.1.0.0 with symbol versions at 1.0.0
- libssl1.0.2: libssl.so.1.0.2 with symbol versions at 1.0.2
- libssl1.1: libssl.so.1.1 (don't know about symbol versions)

What we have:
- openssl-1.0: libssl.so.1.0.0 with symbol versions at 1.0.2
- openssl: libssl.so.1.1 (don't know about symbol versions)

Debian chose to package OpenSSL 1.0.2 for Stretch with a bumped soname version and bumped symbol versions. For jessie-backports they decided to keep 1.0.0 soname and 1.0.0 symbol versions.

IMHO our package is highly incompatible with Debian. Either we bump soname to 1.0.2 or downgrade symbol versions to 1.0.0 by taking the symbol versioning patch from jessie-backports. Note that both ways will break either soname or ABI and requires a recompile of everything that was compiled against our current openssl-1.0 package.

Edit:
Fedora uses libssl.so.10 for their OpenSSL 1.0.x packages. library versions are mixed 1.0.1 and 1.0.2.

Well, the whole situation is a mess, and all because openssl 1.0 didn't version their symbols. From what I can see openssl 1.1 does have symbol versioning upstream, so this shouldn't be a problem in the future.

If they had done symbol versions in openssl 1.0, they would have SSL_CTX_new@@OPENSSL_1_0_0, since it was available since 1.0. That's what happening for 1.1; there is SSL_CTX_new@@OPENSSL_1_1_0. When they release 1.1.2 the symbols specific to that version would be foo@@OPENSSL_1_1_2, but the old ones like SSL_CTX_new would be OPENSSL_1_1_0.

IMO whoever decided to use OPENSSL_1.0.2d for symbols present since 1.0 made a mistake.

So it seems the two options are a) use the wrong version (OPENSSL_1.0.2d) for ever and ever, or b) use the correct version (OPENSSL_1.0.0) and require rebuilding.

I'm not so sure which is best anymore, but I don't think the current situation is ideal.

I can confirm that these symbols are a problem. I would like to add that some proprietary executables also depend on the old behavior. For example I cannot run Deus Ex: MD anymore since the change:

---
>>> Adding process 10904 for game ID 337000
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
===
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/hpcmango/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libldap_r-2.4.so.2: no version information available (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/liblber-2.4.so.2: no version information available (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
/srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/DeusExMD: /usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /srv/steam/omangold/steamapps/common/Deus Ex Mankind Divided/bin/../lib/x86_64/libcurl.so.4)
--

Re-using Debian's patch would be best, since a lot of such software is built against either Debian or Ubuntu libraries. (libclassicclient here requires OPENSSL_1.0.0 and OPENSSL_1.0.1, for example.)

Some proprietary software don't work anymore (eg. some Steam games, JetBrains Toolbox)...
Since we only have control over open-source software, I think the best option is to do as how Debian does, and rebuild all Arch's packages.
BTW, as I said in the other bug report (https://bugs.archlinux.org/task/53618#comment157324), by using setting LD_LIBRARY_PATH and using the AUR package libopenssl-1.0-compat, Jetbrains Toolbox works again...

PS: Jetbrains Toolbox can be downloaded for free from the jetbrains website and it doesn't require an account, if anyone wants to verify if the patch works...

Wouldn't it help to build it the same way as Debian, meaning having two 1.0.x libraries with different symbol versions:

- libssl.so.1.0.0 with symbol versions at 1.0.0
- libssl.so.1.0.2 with symbol versions at 1.0.2

?