• google-earth segfaults on Mga8

    From William Unruh@2:250/1 to All on Thu May 13 17:08:58 2021
    I just upgraded to Mga8, and google earth stopped working. It is google-earth-pro-stable, both the latest version and one from 2019 whose
    rpm I happened to have lying around (7.3.2.5776-0).
    The response is segfault.
    /bin/google-earth-pro: line 43: 244611 Segmentation fault (core dumped) LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./googleearth-bin "$@"

    Doing an strace on /opt/google/earth-pro/googleearth-bin ( with LD_LIBRARY_PATH adjusted to
    also point to /opt/google/earth-pro)
    I get at the end

    futex(0x7fabccb9bc50, FUTEX_WAKE_PRIVATE, 2147483647) = 0
    openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = 3
    fstat(3, {st_mode=S_IFREG|0644, st_size=11229, ...}) = 0
    read(3, "#\n# OpenSSL example configuratio"..., 4096) = 4096 stat("/etc/crypto-policies/back-ends/opensslcnf.config", {st_mode=S_IFREG|0644, st_size=571, ...}) = 0
    openat(AT_FDCWD, "/etc/crypto-policies/back-ends/opensslcnf.config", O_RDONLY) = 4
    fstat(4, {st_mode=S_IFREG|0644, st_size=571, ...}) = 0
    read(4, "CipherString = @SECLEVEL=2:kEECD"..., 4096) = 571
    read(4, "", 4096) = 0
    close(4) = 0
    read(3, "ng, T61String, BMPString.\n# pkix"..., 4096) = 4096
    read(3, "rityKeyIdentifier=keyid:always\n\n"..., 4096) = 3037
    read(3, "", 4096) = 0
    close(3) = 0
    futex(0x7fabccb9bc80, FUTEX_WAKE_PRIVATE, 2147483647) = 0
    - --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
    +++ killed by SIGSEGV (core dumped) +++

    which makes it seem it might be a problem in openssl, but then I have no
    idea what futex is or whether it is the problem.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Thu May 13 20:47:12 2021

    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with cd /opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.


    On 2021-05-13, William Unruh <unruh@invalid.ca> wrote:
    I just upgraded to Mga8, and google earth stopped working. It is google-earth-pro-stable, both the latest version and one from 2019 whose
    rpm I happened to have lying around (7.3.2.5776-0).
    The response is segfault.
    /bin/google-earth-pro: line 43: 244611 Segmentation fault (core dumped) LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./googleearth-bin "$@"

    Doing an strace on /opt/google/earth-pro/googleearth-bin ( with LD_LIBRARY_PATH adjusted to
    also point to /opt/google/earth-pro)
    I get at the end

    futex(0x7fabccb9bc50, FUTEX_WAKE_PRIVATE, 2147483647) = 0
    openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = 3
    fstat(3, {st_mode=S_IFREG|0644, st_size=11229, ...}) = 0
    read(3, "#\n# OpenSSL example configuratio"..., 4096) = 4096 stat("/etc/crypto-policies/back-ends/opensslcnf.config", {st_mode=S_IFREG|0644, st_size=571, ...}) = 0
    openat(AT_FDCWD, "/etc/crypto-policies/back-ends/opensslcnf.config", O_RDONLY) = 4
    fstat(4, {st_mode=S_IFREG|0644, st_size=571, ...}) = 0
    read(4, "CipherString = @SECLEVEL=2:kEECD"..., 4096) = 571
    read(4, "", 4096) = 0
    close(4) = 0
    read(3, "ng, T61String, BMPString.\n# pkix"..., 4096) = 4096
    read(3, "rityKeyIdentifier=keyid:always\n\n"..., 4096) = 3037
    read(3, "", 4096) = 0
    close(3) = 0
    futex(0x7fabccb9bc80, FUTEX_WAKE_PRIVATE, 2147483647) = 0
    --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
    +++ killed by SIGSEGV (core dumped) +++

    which makes it seem it might be a problem in openssl, but then I have no
    idea what futex is or whether it is the problem.



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Fri May 14 00:33:32 2021
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Fri May 14 01:20:57 2021
    On Thu, 13 May 2021 19:33:32 -0400, TJ <TJ@noneofyour.business> wrote:

    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    Presumably if they ever bother rebuilding the linux package they well use the 1.1
    versions of the libraries as they include security fixes not present in the 1.0.0
    versions, in which case the manual fix will no longer be needed.

    The lack of maintenance makes it pretty clear they want people to use the web version to make tracking the usage more complete for their data harvesting.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Fri May 14 02:01:07 2021
    On 2021-05-13, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    It is very strange. Doing strace, google-earth directly asks for libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in
    /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    The suggestion was made somewhere (by you?) that Mageia supply a script
    which would load google-earth. If they did, they could put in something
    to put in those links.
    (but this bug might also frighten them off from doing so).

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Fri May 14 02:02:56 2021
    On 2021-05-14, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Thu, 13 May 2021 19:33:32 -0400, TJ <TJ@noneofyour.business> wrote:

    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    Presumably if they ever bother rebuilding the linux package they well use the 1.1
    versions of the libraries as they include security fixes not present in the 1.0.0
    versions, in which case the manual fix will no longer be needed.

    The lack of maintenance makes it pretty clear they want people to use the web version to make tracking the usage more complete for their data harvesting.

    I have not found any way of reporting a bug in google-earth to Google in
    a not terribly deep attempt to find some way of doing so.


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Fri May 14 13:29:47 2021
    On 5/13/21 9:01 PM, William Unruh wrote:
    On 2021-05-13, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    It is very strange. Doing strace, google-earth directly asks for libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    The suggestion was made somewhere (by you?) that Mageia supply a script
    which would load google-earth. If they did, they could put in something
    to put in those links.
    (but this bug might also frighten them off from doing so).

    TJ

    I don't remember making the suggestion, but I suppose it's possible. At
    one time Mageia did offer such a package with Google Earth Pro's
    predecessor, Google Earth. I don't know why we stopped, as I wasn't yet
    a part of the Mageia team at the time.

    I wouldn't be surprised if it was a copyright permission issue of some
    kind. Something like how we used to provide pre-built kernel modules for
    the nVidia drivers, but now can't. They now have to be built locally.
    But that's just idle speculation on my part. Like I said, I don't know.

    As for the version mystery, I'm sure I don't know that one, either.
    There could be a reason for it, or it could just be sloppy coding.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Fri May 14 13:57:34 2021
    On 5/14/21 8:29 AM, TJ wrote:
    On 5/13/21 9:01 PM, William Unruh wrote:
    On 2021-05-13, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be
    fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0  libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro. >>>
    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    It is very strange. Doing strace, google-earth directly asks for
    libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in
    /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    The suggestion was made somewhere (by you?) that Mageia supply a script
    which would load google-earth. If they did, they could put in something
    to put in those links.
    (but this bug might also frighten them off from doing so).

    TJ

    I don't remember making the suggestion, but I suppose it's possible. At
    one time Mageia did offer such a package with Google Earth Pro's predecessor, Google Earth. I don't know why we stopped, as I wasn't yet
    a part of the Mageia team at the time.

    I wouldn't be surprised if it was a copyright permission issue of some
    kind. Something like how we used to provide pre-built kernel modules for
    the nVidia drivers, but now can't. They now have to be built locally.
    But that's just idle speculation on my part. Like I said, I don't know.

    As for the version mystery, I'm sure I don't know that one, either.
    There could be a reason for it, or it could just be sloppy coding.

    TJ
    Come to think of it, it may have been Mandriva that offered to install
    Google Earth. Memories have a way of blending together the farther back
    I look.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Fri May 14 14:10:05 2021
    On 5/13/21 9:01 PM, William Unruh wrote:
    On 2021-05-13, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro.

    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    It is very strange. Doing strace, google-earth directly asks for libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    The suggestion was made somewhere (by you?) that Mageia supply a script
    which would load google-earth. If they did, they could put in something
    to put in those links.
    (but this bug might also frighten them off from doing so).

    TJ

    I have to get to work so I don't have time to check it out now, but I
    wonder what would happen if, instead of the libssl.so and libcrypto.so
    links in /opt/google/earth/pro pointing to the versions supplied by
    Google, suppose they pointed to the newer system versions?

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Fri May 14 16:27:05 2021
    On 2021-05-14, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 9:01 PM, William Unruh wrote:
    On 2021-05-13, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 3:47 PM, William Unruh wrote:
    This is discussed in bug 28018 on Mageia bugzilla

    The solutions is
    Google Earth Pro has the problem on Mga8 of segfaulting which can be fixed with
    cd/opt/google/earth/pro/
    ln -s libssl.so.1.0.0 libssl.so.1.1
    ln -s libcrypto.so.1.0.0 libcrypto.so.1.1

    all run as root.
    https://bugs.mageia.org/show_bug.cgi?id=28018

    You will have to redo this fix every time you upgrade google-earth-pro. >>>
    Yes, it's an upstream problem that will have to be addressed by Google.
    The Mageia devs can't touch it.

    It is very strange. Doing strace, google-earth directly asks for
    libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in
    /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    The suggestion was made somewhere (by you?) that Mageia supply a script
    which would load google-earth. If they did, they could put in something
    to put in those links.
    (but this bug might also frighten them off from doing so).

    TJ

    I have to get to work so I don't have time to check it out now, but I
    wonder what would happen if, instead of the libssl.so and libcrypto.so
    links in /opt/google/earth/pro pointing to the versions supplied by
    Google, suppose they pointed to the newer system versions?

    You would get a crash. At present, google-earth-pro looks for
    libcrypto.1.1 in /opt/google/earth/pro. If it is not there, it looks in
    /lib64 and loads the version there. So if you do not have that link in /opt/google/earth/pro it does exactly what you suggest, and loads the
    newer system version. And segfaults. Note that I have found that if you
    do not have the libssl link, but do have the libcrypto link, then it
    does not crash. I have not used it for any length of time, so it could
    still be problematic, but the immediate crash is not there. This
    suggests to me that the problem is not in google-earth, but rather is in libcrypto. It has broken backwards compatibility. Unless of course
    google in its wisdom packaged an incompatible version of libcrypto.1.0.0
    with google-earth (Ie, produced their own version) in which case they
    are legally obliged to produce the source code for that altered version.
    When did the mainline transformation from libcrypto 1.0.0 to 1.1 occur?



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat May 15 03:25:43 2021
    On Fri, 14 May 2021 11:27:05 -0400, William Unruh <unruh@invalid.ca> wrote:

    When did the mainline transformation from libcrypto 1.0.0 to 1.1 occur?

    For Mageia, the transition occurred in Mageia 8 development in Aug. 2019. All of the packages that use that library had to be changed as part of the update (rebuilt to pick up changes in the header files used to define the parameters passed between the lib and the calling application).

    Changes that are not backward compatible are not unusual with lib version changes,
    which is why Mageia limits what version changes are allowed in a stable release.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat May 15 02:59:53 2021
    On Fri, 14 May 2021 08:29:47 -0400, TJ <TJ@noneofyour.business> wrote:
    I don't remember making the suggestion, but I suppose it's possible. At
    one time Mageia did offer such a package with Google Earth Pro's
    predecessor, Google Earth. I don't know why we stopped, as I wasn't yet
    a part of the Mageia team at the time.

    Checked my mail archive. Mageia has never packaged any version of google-earth due to it's license. https://policies.google.com/terms specifically states ... "You may not copy, modify, distribute, sell, or lease any part of our services or software."

    The only thing google produces that we are allowed to distribute is their fonts which are distributed under the OFL license ... https://en.wikipedia.org/wiki/SIL_Open_Font_License

    Even chromium-browser is not the google version. It's the open source version from
    http://www.chromium.org

    I suspect you may be thinking of the old get-flash packages.

    Regards, Dave Hodgins


    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat May 15 03:08:29 2021
    On Thu, 13 May 2021 21:01:07 -0400, William Unruh <unruh@invalid.ca> wrote:
    It is very strange. Doing strace, google-earth directly asks for libcrypto.so.1.1 . If it is not in /opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    It doesn't hard code libcrypto.so.1.1. It calls something that the dynamic linker
    determines comes from that lib, so then either the system version is used or if present in the same directory as google-earth, that version is loaded/used.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Sat May 15 13:21:27 2021
    On 5/14/21 9:59 PM, David W. Hodgins wrote:
    On Fri, 14 May 2021 08:29:47 -0400, TJ <TJ@noneofyour.business> wrote:
    I don't remember making the suggestion, but I suppose it's possible. At
    one time Mageia did offer such a package with Google Earth Pro's
    predecessor, Google Earth. I don't know why we stopped, as I wasn't yet
    a part of the Mageia team at the time.

    Checked my mail archive. Mageia has never packaged any version of google-earth
    due to it's license. https://policies.google.com/terms specifically
    states ...
    "You may not copy, modify, distribute, sell, or lease any part of our services or software."

    The only thing google produces that we are allowed to distribute is
    their fonts
    which are distributed under the OFL license ... https://en.wikipedia.org/wiki/SIL_Open_Font_License

    Even chromium-browser is not the google version. It's the open source version from
    http://www.chromium.org

    I suspect you may be thinking of the old get-flash packages.

    Regards, Dave Hodgins


    No, it was definitely google earth, but as mentioned before, it could
    easily have been from Mandriva. Maybe even Mandrake, but I don't think
    Earth dates back that far. I specifically remember being disappointed
    when it was no longer available after a new release, and I had to go
    find a way to download it myself for install.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Sat May 15 13:33:08 2021
    On 5/13/21 9:01 PM, William Unruh wrote:

    It is very strange. Doing strace, google-earth directly asks for libcrypto.so.1.1 . If it is not in/opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    I suspect that Google did not supply the "wrong version" of the
    libraries at all, but rather supplied the versions that were the latest
    at the time it was built, to assure it would work on systems with older versions of the packages. The problem is more one of Google not doing sufficient maintenance.

    When was the "latest" Google Earth built, anyway?

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sat May 15 17:12:35 2021
    On 2021-05-15, TJ <TJ@noneofyour.business> wrote:
    On 5/13/21 9:01 PM, William Unruh wrote:

    It is very strange. Doing strace, google-earth directly asks for
    libcrypto.so.1.1 . If it is not in/opt/google/earh/pro/ it uses the
    system's version, and crashes. If you put in that link in
    /opt/google/earth/pro from libcrypto.so.1.1 to libcrypto.so.1.0.0 then
    things work. So why would google supply the wrong version of a library?

    I suspect that Google did not supply the "wrong version" of the
    libraries at all, but rather supplied the versions that were the latest
    at the time it was built, to assure it would work on systems with older versions of the packages. The problem is more one of Google not doing sufficient maintenance.

    When was the "latest" Google Earth built, anyway?

    The latest one I have installed is google-earth-pro-stable-7.3.2.5776 fromMar 4
    2019.
    So as David (?) suspected, the library loader must look for the latest
    version of libcrypto or its contents, and then ask for that version.
    Although since libcrypto.1.0.0 is first in LD_LIBRARY_PATH one would
    expect it to be found first and used. But it is not.

    That sounds like a problem with the shared library loader.


    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sat May 15 18:30:33 2021
    On Sat, 15 May 2021 12:12:35 -0400, William Unruh <unruh@invalid.ca> wrote:
    The latest one I have installed is google-earth-pro-stable-7.3.2.5776 fromMar 4
    2019.
    So as David (?) suspected, the library loader must look for the latest version of libcrypto or its contents, and then ask for that version.
    Although since libcrypto.1.0.0 is first in LD_LIBRARY_PATH one would
    expect it to be found first and used. But it is not.

    That sounds like a problem with the shared library loader.

    It's working as designed. The ldconfig program parses the directory names in /etc/ld.so.conf and based on the libs present in those directories updates /etc/ld.so.cache, which the dynamic linker uses to pick which lib, and what directory to load it from if a copy is not present in the same directory as the executable.

    Google provides copies of all of the libs it needs, under the assumption they may
    not be available at the system level.

    In Mageia 7 that worked ok as the dynamic linker picks libcrypto.so.1.0.0 as the lib to load and finds a copy in /opt/google/earth/pro/libcrypto.so.1.0.0 that's what it uses. In Mageia 8 the dynamic linker picks libcrypto.so.1.1. Google didn't provide a copy of that lib in /opt/google/earth/pro/ so the system level libcrypto file is used. By creating the symlink, when the dynamic linker looks for libcrypto.so.1.1 it finds a copy in the same lib as google-earth,
    even though it's actually the old lib.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Sat May 15 20:31:17 2021
    On 2021-05-15, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Sat, 15 May 2021 12:12:35 -0400, William Unruh <unruh@invalid.ca> wrote:
    The latest one I have installed is google-earth-pro-stable-7.3.2.5776 fromMar 4
    2019.
    So as David (?) suspected, the library loader must look for the latest
    version of libcrypto or its contents, and then ask for that version.
    Although since libcrypto.1.0.0 is first in LD_LIBRARY_PATH one would
    expect it to be found first and used. But it is not.

    That sounds like a problem with the shared library loader.

    It's working as designed. The ldconfig program parses the directory names in /etc/ld.so.conf and based on the libs present in those directories updates /etc/ld.so.cache, which the dynamic linker uses to pick which lib, and what directory to load it from if a copy is not present in the same directory as the
    executable.

    Google provides copies of all of the libs it needs, under the assumption they may
    not be available at the system level.

    In Mageia 7 that worked ok as the dynamic linker picks libcrypto.so.1.0.0 as the lib to load and finds a copy in /opt/google/earth/pro/libcrypto.so.1.0.0 that's what it uses. In Mageia 8 the dynamic linker picks libcrypto.so.1.1. Google didn't provide a copy of that lib in /opt/google/earth/pro/ so the system level libcrypto file is used. By creating the symlink, when the dynamic
    linker looks for libcrypto.so.1.1 it finds a copy in the same lib as google-earth,
    even though it's actually the old lib.

    Actually 7 has both libcrypto.1.0.0 and libcrypto.1.1

    lrwxrwxrwx 1 root root 16 Feb 27 11:02 /usr/lib64/libcrypto.so -> libcrypto.so.1.1
    -r-xr-xr-x 1 root root 2387048 Feb 27 11:11 /usr/lib64/libcrypto.so.1.0.0 -rwxr-xr-x 1 root root 2846600 Feb 27 11:03 /usr/lib64/libcrypto.so.1.1

    They come from
    compat-openssl10-1.0.2u-1.2.mga7.src.rpm
    and
    openssl-1.1.0l-1.3.mga7.src.rpm
    So it is strange, if your theory is right, that google-earth-pro does
    not find the libcrypto.so.1.1

    In Mageia 7 even though /lib64/libcrypto.so.1.1 exists, googleearth
    looks for and finds libcrypto.so.1.0.0 in the /opt/google/earth/pro
    directory.
    In Mga8, it looks for libcrypt.so.1.1. So, the operation of ldconfig
    seems to have changed from Mga7 to Mga8.
    Or google earth seems to have explicitly started looking for
    libcrypto.so.1.1 Ie, is the "bug" in the library loader rather than google-earth-pro? It seems to have changed its behaviour between Mga7
    and Mga8.






    Regards, Dave Hodgins


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)