4.9.3 preparations

Paul Buxton paulbuxton.mail at googlemail.com
Mon Sep 9 03:26:22 PDT 2019


Hmm, doesn't make any difference on mine.
Googling I did fine some references that suggest that Qt networking loads
libssl and libcrypto using dlopen, which would not show up as a dependency
through ldd....
https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp
So whilst ldd is listing that it is linked against 1.0 it may actually be
picking up 1.1 from your library path.

On Mon, Sep 9, 2019 at 10:25 AM Dirk Hohndel <dirk at hohndel.org> wrote:

> On Mon, Sep 09, 2019 at 10:03:44AM +0100, Dirk Hohndel wrote:
> > On Mon, Sep 09, 2019 at 09:50:07AM +0100, Paul Buxton wrote:
> > > Reviewing my log I also see an message Incompatible version of SSL
> > >
> > > Doing some googling this looks relevant.
> > > https://github.com/probonopd/linuxdeployqt/issues/209
> > >
> > > Basically it looks like Qt>5.10 expect to use openssl 1.1.
> > > The package we are supplying includes openssl 1.0
> > > I am guessing that on distros with newer versions of Openssl the
> Appimage
> > > is picking up the right version to use.
> >
> > Our emails crossed (i.e., I didn't see yours before sending mine). Yes,
> > that is a reasonable conclusion. Now I need to figure out if I even can
> > include an openssl 1.1 library with the Trusty based build...
>
> No, that isn't the problem:
>
> Let's force the AppImage to use the bundled openssl library... checking
> that this works:
>
> $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH ldd
> /tmp/.mount_SubsurMl62lz/AppRun  | grep ssl
>         libssl.so.1.0.0 =>
> /tmp/.mount_SubsurMl62lz/usr/lib/libssl.so.1.0.0 (0x00007f55aeb85000)
>
> OK, so this picks up the included one
>
> $ LD_LIBRARY_PATH=/tmp/.mount_SubsurMl62lz/usr/lib:$LD_LIBRARY_PATH
> /tmp/.mount_SubsurMl62lz/AppRun  -v
> Subsurface v4.9.3,
> built with libdivecomputer v0.7.0-devel-Subsurface-NG
> (ce6d9896a79afaa82641132e338f8744714c8593)
> built with Qt Version 5.12.4, runtime from Qt Version 5.12.4
> built with libgit2 0.26.0
> [...]
> no SSL warnings
> [...]
>
> cloud URL set as "
> https://cloud.subsurface-divelog.org//git/dirk@hohndel.org[dirk@hohndel.org]
> "
> Opening cloud storage from: "
> https://cloud.subsurface-divelog.org//git/dirk@hohndel.org[dirk@hohndel.org]
> "
> git storage: Synchronising data file
> git storage: update local repo
> sync with remote
> https://cloud.subsurface-divelog.org//git/dirk@hohndel.org[dirk@hohndel.org]
> git storage: Sync with cloud storage
> Cloud storage: checking connection to cloud server
> Checking cloud connection...
> git storage: Waiting for cloud connection (1 second(s) passed)
> git storage: fetch remote
> git storage: Successful cloud connection, fetch remote
> git storage: check remote status
> git storage: try to update
> git storage: Done syncing with cloud storage
> git storage: Load dives from local cache
> git storage: Successfully opened dive data
>
> So there is something weird about that specific SSL library on your
> system, or more specifically there's something that our AppImage doesn't
> like.
>
> I don't think there's a way to force the AppImage to use its bundled SSL
> lib without mounting it - but this might be a workaround for now...
>
> /D
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190909/7daa2d44/attachment.html>


More information about the subsurface mailing list