W dniu 21.12.2019 o 21:12, Simon Heimbach pisze:

Hello everyone,

since I upgraded my system from Leap 15.0 to Leap 15.1 with zypper dup, I cannot use curl on secure connections anymore due to an error between curl and openssl.

Before I was using the command like curl -o /dev/stdout --insecure --user '***:***' -T ~/*** https://webdav.***

but now I get the follwing error message: curl: /usr/lib64/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /usr/local/lib64/libcurl.so)

ldd /usr/bin/curl says: linux-vdso.so.1 (0x00007ffc57ff1000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f667085e000) libmetalink.so.3 => /usr/lib64/libmetalink.so.3 (0x00007f667064e000) libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f66701be000) libz.so.1 => /lib64/libz.so.1 (0x00007f666ffa6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f666fd86000) libc.so.6 => /lib64/libc.so.6 (0x00007f666f9c6000) libnghttp2.so.14 => /usr/lib64/libnghttp2.so.14 (0x00007f666f79e000) libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00007f666f57e000) libssh.so.4 => /usr/lib64/libssh.so.4 (0x00007f666f2f6000) libpsl.so.5 => /usr/lib64/libpsl.so.5 (0x00007f666f0e6000) libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f666ee76000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f666ec26000) libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f666e9ce000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f666e7be000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f666e586000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f666e37e000) /lib64/ld-linux-x86-64.so.2 (0x00007f6670d2e000) libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00007f666dff6000) librt.so.1 => /lib64/librt.so.1 (0x00007f666ddee000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f666db0e000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f666d8d6000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f666d6ce000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f666d4be000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f666d2a6000) libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f666d086000) libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f666ce7e000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f666cc4e000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f666c9be000)

I am pretty sure the upgrade went well otherwise. I use the system in production and everything else runs really smoothly. I have reinstalled curl, libcurl, openssl and libopenssl but with no success.

Anyone else haveing a similar issue and an idea to solve this?

Thank you very much! Simon

You shouldn't have libcurl in /usr/*local*/lib64. If you do and it was compiled for previous version, no wonder it's incompatible with newer system. It's also a bit surprising, that ldd for curl shows that it's not using /usr/local. Have you run ldd as root? Anyway, here's what to do: 1) check what you have in /usr/local and possibly remove it 2) run "sudo ldconfig"

On 2019/12/21 12:12, Simon Heimbach wrote:

Hello everyone,

since I upgraded my system from Leap 15.0 to Leap 15.1 with zypper dup, I cannot use curl on secure connections anymore due to an error between curl and openssl.

Before I was using the command like curl -o /dev/stdout --insecure --user '***:***' -T ~/*** https://webdav.***

but now I get the follwing error message: curl: /usr/lib64/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /usr/local/lib64/libcurl.so)

Anyone else haveing a similar issue and an idea to solve this?

--- Too many times. It's the linux equivalent of MS's DLL Hell, that MS solved 10+ years ago with side-by-side libs -- something that linux has yet to adopt or get. For some reason linux is getting worse in this area with more and more libs including version info, and locking each other out. I've been told it shouldn't happen if it is done right, as the later libs should have a a compatibility section so programs using earlier versions of the lib will still continue to work. At least that's what I was "told" -- I have yet to see it work that way but have seen many programs break when some libs are updated. In several cases (but not all), I put both versions of libs in place, like in the above case, I might have tried libssl.so.1.1 and libssl.so.1.1.1 If the programs would link with the minor version they worked with, this would be alot more successful, since what seem to be happening, is that libssl.so.1.1 might point to libssl.so.1.1.3 -- but that lib is broken in that it should deal with prior versions (especially minor) like 1.1.1. The Dll hell from MS, required there be only 1 version of a shared lib in memory at one time. That version needed to handle variations or programs wouldn't load (usually wouldn't load). Now, they can have multiple versions of the same lib present in the lib dir, so different programs built for different lib-versions can work -- and programs written for XP-era can still run on Win7 (or Win10). Vs. linux programs which often don't work if you upgrade a minor release as you have experienced. Like many computer problems, today, you find that those problems were often already solved 10-20 years ago -- even unix could handle making differently versioned - libs with programs linking with the one they need (vs. requiring all use the same lib). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org