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.

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.
>
>

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

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.

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

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.
>

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

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

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

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?

>

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.

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.

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.

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

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

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

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.

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
>