Bug 28018 - Google Earth: how to run it on Mageia 8
Summary: Google Earth: how to run it on Mageia 8
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords: IN_ERRATA8
: 28653 28912 29650 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-01-05 18:34 CET by Roger Checa
Modified: 2021-11-12 06:08 CET (History)
9 users (show)

See Also:
Source RPM:
CVE:
Status comment: workaround here: https://bugs.mageia.org/show_bug.cgi?id=28018#c17


Attachments

Description Roger Checa 2021-01-05 18:34:12 CET
Description of problem:
Google Earth doesn't start anymore

Version-Release number of selected component (if applicable):
Mageia 8 pre-release

How reproducible:
Downloading googleearth from
https://www.google.fr/earth/download/gep/agree.html
updating "lib64curl4" from 7.73.0-1 to 7.74.0-1

Steps to Reproduce:
When downloading and installing googleearth on the M8 pre-release out-of-the-box, the soft perfectly works.
But after updating the lib "lib64curl4" from 7.73.0-1 to 7.74.0-1 googleearth won't start anymore.
To be noted : When updating "curl" alone without the lib, googleearth goes on working.
Thanks
Comment 1 Lewis Smith 2021-01-05 21:21:31 CET
Is the problem in lib64curl4, or GoogleEarth (like a dependency on a particular library version)?

This is the only reference I found:
 https://aur.archlinux.org/packages/google-earth-pro/?O=10&PP=10#comment-780817
The 'Latest Comments' look temptingly relevant, if abbreviated.
Selected quotations:
----------------------
I can update curl and libcurl-compat to 7.74.0-1 provided that I add the libraries from curl-7.73.0-1-x86_64.pkg.tar.zst to /opt/google/earth/pro/
libcurl.so.4.7.0 libcurl.so.4 -> libcurl.so.4.7.0 libcurl.so -> libcurl.so.4.7.0

Warning: security issue was found in curl 7.73.0. It's fixed in curl 7.74

Might also force depends=('curl<7.74.0') for now even tho it's a base package.
Downside is theoretically having to follow when it's fixed in git for the 'curl>=7.74.0.x' whatever.

this is not a curl issue, it is a google earth issue.
--------------------
GoogleEarth is not one of our packages (it *is* for AUR), so it is not in our power to fix it. However, you found a temporary workaround - meaning specifically stopping updates for that library. Because Cauldron does not hold old package versions, I am not sure about being able to offer 7.73.0-1 retrospectively.

Leaving this with BugSquad for other comments for now.

CC: (none) => lewyssmith
Source RPM: lib64curl4 => curl-7.74.0-1.mga8.src.rpm

Comment 2 David Walser 2021-01-06 00:21:48 CET
This is definitely a Google Earth problem, so they should be the ones to fix it.

However, if you report it upstream to cURL (assuming someone already hasn't, as it's apparently a known issue), they may be able to implement a workaround that we can add.
Comment 3 Lewis Smith 2021-01-07 12:04:49 CET
@Roger : can you please do that, at:
 https://github.com/curl/curl/issues
I could not see this in the presented bug list - nor any way of searching them.

If you do raise a bug there, please note its URL in that box at the head of this bug.

Keywords: (none) => UPSTREAM

Comment 4 Roger Checa 2021-01-07 14:59:02 CET
@Lewis Smith
Not quite sure of what you're asking me to do. In the list presented I didn't see any relation with our subject.
I only noted a bug of curl 7.74 (not its lib) with NSS, crypto, and pulseUI-VPN.
#6306.
I agree the new bug is not part of Mageia, the same problem (since update to lib64curl4 7.74.0) exists with other distros ("Rosa" I'm using too, amongst them).
Now, assigning the bug to Google-earth or Curl doesn't get into my skills.
Thanks
Comment 5 Roger Checa 2021-01-07 16:41:38 CET
@Lewis Smith
Sorry to have to modify my last message :
"Google Earth Pro" (version 7.3.3.7721 - may 2020) works fine with distrib "ROSA" and "curl 7.74.0" and "libcurl4 7.74.0".
Nevertheless, I am not capable to say the version number of the one which doesn't open anymore with Mageia.
I only could check the number of octets in both google versions of each distrib and it is different. This could mean "only" the sole last version of Google Earth (loaded on Mageia) bugs with the curl lib.
Thanks
Comment 6 Lewis Smith 2021-01-07 20:22:19 CET
(In reply to Roger Checa from comment #4)
> Not quite sure of what you're asking me to do. In the list presented I
> didn't see any relation with our subject.
We are asking *you* to raise a bug upstream with cURL, as DavidW suggested "they may be able to implement a workaround that we can add".
There is a button 'New Issue' top right; it asks you to create an account first, looks easy.
The worst that can happen is they say "Not our affair".

(In reply to Roger Checa from comment #5)
> "Google Earth Pro" (version 7.3.3.7721 - may 2020) works fine with distrib
> "ROSA" and "curl 7.74.0" and "libcurl4 7.74.0".
I see the problem: you cannot even start GoogleEarth to see its version. The downloaded filename might give a clue.
The one you quote that works with Rosa is quite old. I wonder whether you have a more recent one. Explore the G-E downloads to see whether the May '20 one is shown; if so, download & try that.
Or you could try installing the Rosa downloaded one on Mageia. We are related! If you double-click it (assuming an .rpm file) in a file manager, it should offer to install it. Sometimes RPMs from other distributions like Fedora install OK on Mageia - and vice-versa.
Comment 7 Roger Checa 2021-01-08 15:49:57 CET
@Lewis Smith
- Ok, clear now about raising bug to mainstream "cURL".
But before that I made some trials as I have a doubt concerning the responsible of the bug.
For all trials => same last "GE-pro" package (7.3.3.7786 -july 2020) used with all distribs :
1/ Mageia 7 with "lib64curl4" 7.71.0 + last GE-pro (7.3.37721) = working.
2/ Mageia 8 with "lib64curl4" 7.73.0 + last GE-pro (7.3.37721) = working.
(with "lib64curl4" 7.74.0 + last GE-pro (7.3.37721) = not working.)
...the doubt is between cURL(74) and Mageia...
but :
3/ Rosa with "lib64curl4" 7.74.0 + last GE-pro (7.3.37721) = working.
My conclusions are :
A/ The last "GE-pro" package seems really OK;
B/ "lib64curl4 7.74.0" is OK with Rosa;
C/ "lib64curl4 7.74.0" is KO with Mageia 8;
which means I'm not certain -but I'm not expert at all- the bug is with "cURL", since working with Rosa and same GE-pro package.
Thanks
Comment 8 Lewis Smith 2021-01-10 11:33:51 CET
Thank you for your research, nicely presented.
(In reply to Roger Checa from comment #7)
> For all trials => same last "GE-pro" package (7.3.3.7786 -july 2020) used
> with all distribs :
> 1/ Mageia 7 with "lib64curl4" 7.71.0 + last GE-pro (7.3.37721) = working.
> 2/ Mageia 8 with "lib64curl4" 7.73.0 + last GE-pro (7.3.37721) = working.
> (with "lib64curl4" 7.74.0 + last GE-pro (7.3.37721) = not working.)
> 3/ Rosa with "lib64curl4" 7.74.0 + last GE-pro (7.3.37721) = working.
> My conclusions are :
> A/ The last "GE-pro" package seems really OK;
> B/ "lib64curl4 7.74.0" is OK with Rosa;       **********************
> C/ "lib64curl4 7.74.0" is KO with Mageia 8;
This is clear enough; but the remarks in comment 1 show that it is not just Mageia where this problem has surfaced.

You can still try installing the Rosa lib64curl4 7.74.0 (use the --replacepkgs option on urpmi). I think you should; it would help. You can test it first:
 # urpmi --replacepkgs --test <path-to-the-Rosa-RPM>
If that looks OK, do it (without --test).

All I can think of, as a kind & desperate measure, is to compare the Rosa lib64curl4 7.74.0 RPM with ours. I am not asking you to do that.
One of our packagers may be willing & able to tell you what information is needed (RPM red tape); and how to extract it. The entire RPM will be too big to attach to this bug; the sizeable binary would be irrelevant.

Although technically this is not Mageia's affair, it *is* in our interest that GoogleEarth should work with it: the application is too important.

Assigning globally, CC'ing the packagers most recently involved. This is a charitable request to crack if we can, or ditch otherwise.

Keywords: UPSTREAM => (none)
Assignee: bugsquad => pkg-bugs
CC: (none) => mageia, shlomif
Summary: updating "lib64curl4" doesn't allow Google Earth to start => updating "lib64curl4" to 7.74.0-1 kills Google Earth, which worked with 7.73.0-1. Rosa works with 7.74.0-1

Comment 9 Roger Checa 2021-01-10 21:01:16 CET
@Lewis Smith

1/ I downloaded "lib64curl4 7.74.0-1" and "lib64curl-devel-7.74.0-1" from Rosa's depositories, but they won't install on M8, because "libssl.so-xxx" and "libcrypto.so-xxx" are missing.
I couldn't localize them nor on the M8 neither on the M7, and yet "GE-pro" works on both, without these 2 libs. The names of the missing libs are probably different here.


2/ (remember my M8 was still with "lib64curl 7.7.73.0" and "curl 7.73.0"). After 2 new updates yesterday and today on the M8, the kernel was changed twice, and "GE-pro refused" then to start.
I noticed the "kernel-devel" and all the stuff needed for compilation (gcc, ncurse,...) were not installed. When I tried to install them, I received a message reading that "lib64curl4" was absent and the installation (of the kernel-devel) was impossible.
I installed only "curl 7.74" (not its lib) and gcc and others, installed together with curl... (were they at this moment, waiting to be installed independently in the MCC, after being blocked by the kernel-devel install?) 
Anyway, GE-pro works back again (always without lib64curl 7.74.0).

I really don't know if all this remarks will help, but I understand that many many things are working together : "kernel devel" - "curl'libs" - "crypto" and "libssl" (or for others => "libressl")'libs", and, would one simple name or location of module be wrong, that the whole process of install collapses.

That's all I am capable to say.
Comment 10 Lewis Smith 2021-01-10 21:50:05 CET
> I downloaded "lib64curl4 7.74.0-1" and "lib64curl-devel-7.74.0-1"
> from Rosa's depositories, but they won't install on M8,
> because "libssl.so-xxx" and "libcrypto.so-xxx" are missing.
You have worked hard on this. Re the libraries wanted by Rosa:
*libssl.so-xxx
libssl.so is provided by lib64openssl-devel
libssl.so.1.1 by lib64openssl1.1
but note the symbolic link, there is just one library:
 $ ls -l /usr/lib64/libssl.so*                               
 lrwxrwxrwx 1 root root     13 Rha  10 12:22 /usr/lib64/libssl.so -> 
libssl.so.1.1*                                                                              
 -rwxr-xr-x 1 root root 659320 Rha  10 12:23 /usr/lib64/libssl.so.1.1*

*libcrypto.so-xxx
libcrypto.so is also provided by lib64openssl-devel
libcrypto.so.1.1 also by lib64openssl1.1
similarly note the symbolic link, there is just one library:
 $ ls -l /usr/lib64/libcrypto.so*
 lrwxrwxrwx 1 root root      16 Rha  10 12:22 /usr/lib64/libcrypto.so -> libcrypto.so.1.1*                                                                       
 -rwxr-xr-x 1 root root 3213688 Rha  10 12:23 /usr/lib64/libcrypto.so.1.1*

See whether you have (I have both, not sure why the -devel pkg):
 $ rpm -q lib64openssl1.1
 lib64openssl1.1-1.1.1i-1.mga8
 $ rpm -q lib64openssl-devel
 lib64openssl-devel-1.1.1i-1.mga8
and what you have in /usr/lib64/libcrypto.so* & /usr/lib64/libssl.so*
If you have neither, try just lib64openssl1.1 to start with.

All this to try to satisfy the Rosa lib64curl4 7.74.0-1. This is just experimenting, you understand. I would not get bogged down in -devel packages lightly.
Comment 11 Roger Checa 2021-01-11 17:20:25 CET
@Lewis Smith
Tried all your commands, and everything seems correct except "/usr/lib64/libssl.so.1.0.0" in M7 replaced by a link : "usr/lib64/libssl.so -> /usr/lib64/libssl.so.1.1" in M8 but this is not a reason to block GE-pro.
Despite many tries I never could install the Rosa's lib.
In the end, I updated M8 to "lib64curl4 7.74.0" to newly face the blockage : GE-pro not starting.
Dead for dead, I decided to copy directly "libcurl.so.4.7.0" from Rosa to M8 as I noticed in the "Details" of the modules that one(M8) was 612,4 Kio and the other(Rosa) 565,4 Kio ...and GE-pro started perfectly.
I know this not a permanent solution and above all a serious way to solve a bug, but at least, this should provide you some clue.
The package "lib64curl4" used by Mageia is directly responsible.
Thanks
Comment 12 Roger Checa 2021-01-11 20:57:07 CET
Repo Rosa for "lib64curl4 7.74.0-1"
http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/main/updates/
Comment 13 Lewis Smith 2021-01-11 20:58:25 CET
(In reply to Roger Checa from comment #11)
> Despite many tries I never could install the Rosa's lib.
> In the end, I updated M8 to "lib64curl4 7.74.0" to newly face the blockage :
> GE-pro not starting.
> Dead for dead, I decided to copy directly "libcurl.so.4.7.0" from Rosa to M8
> as I noticed in the "Details" of the modules that one(M8) was 612,4 Kio and
> the other(Rosa) 565,4 Kio ...and GE-pro started perfectly.
Bold; and well done! That should at least help others with the same problem.
Thanks for the URL above.
I hope our packagers will find the difference.

I can help no more, so signing out.

CC: lewyssmith => (none)

Comment 14 Christian Müller 2021-03-01 18:38:38 CET
(In reply to Lewis Smith from comment #13)

> Bold; and well done! That should at least help others with the same problem.
> Thanks for the URL above.

This 'Fix' works for me, too.

CC: (none) => chmos

Comment 15 Roger Checa 2021-03-01 20:34:15 CET
To Christian Müller,
This 'fix' has to be forgotten :
1/ As it brings a lot of other inconvenients in the system;
2/ Because last kernels have solved the problem.
Thanks
Comment 16 Christian Müller 2021-03-02 18:30:05 CET
(In reply to Roger Checa from comment #15)
> To Christian Müller,
> This 'fix' has to be forgotten :
> 1/ As it brings a lot of other inconvenients in the system;

I'm fully aware of that, and I reverted it after testing.

> 2/ Because last kernels have solved the problem.
> Thanks

Not on for me. Google-Earth still not running.
Comment 17 Roger Checa 2021-03-02 18:48:52 CET
Hi Chris,
Sorry, I should have give you the trick.
3 commands root :
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
Good luck
Comment 18 Christian Müller 2021-03-02 18:55:02 CET
(In reply to Roger Checa from comment #17)

> Sorry, I should have give you the trick.
> 3 commands root :
> 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

that did the trick, thank you :)
Comment 19 Aurelien Oudelet 2021-03-02 18:59:02 CET
(In reply to Roger Checa from comment #17)
> Hi Chris,
> Sorry, I should have give you the trick.
> 3 commands root :
> 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
> Good luck

Does this is the only thing to do to be able to have Google Earth Pro running on Mageia 8?

CC: (none) => ouaurelien

Comment 20 Roger Checa 2021-03-02 19:01:14 CET
Yes Aurélien
Comment 21 Roger Checa 2021-03-02 19:51:07 CET
Hi
Trick found by "jybz" :
"""J'en profite pour copier-coller ici aussi le lien vers la ML a propos de google earth :
https://ml.mageia.org/l/arc/qa-discuss/2021-02/msg00430.html
"""
Forum discussions :
https://www.mageialinux-online.org/forum/topic-28405-2+test-iso-rc.php
https://www.mageialinux-online.org/forum/topic-28252-2+google-earth.php
Comment 22 Aurelien Oudelet 2021-03-02 20:17:08 CET
So, this workaround should land in forums as pinned entry.
See comment 17.

As long as we don't ship Google Earth software, closing this.

Version: Cauldron => 8
Status comment: (none) => workaround here: https://bugs.mageia.org/show_bug.cgi?id=28018#c17
Summary: updating "lib64curl4" to 7.74.0-1 kills Google Earth, which worked with 7.73.0-1. Rosa works with 7.74.0-1 => Google Earth: how to run it on Mageia 8
Source RPM: curl-7.74.0-1.mga8.src.rpm => (none)
Resolution: (none) => INVALID
Status: NEW => RESOLVED

Comment 23 peter lawford 2021-03-27 14:06:54 CET
(In reply to Roger Checa from comment #17)
> Hi Chris,
> Sorry, I should have give you the trick.
> 3 commands root :
> 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
> Good luck

it works well on my mageia8, congratulation!

CC: (none) => petlaw726

Comment 24 Al My 2021-03-30 07:50:02 CEST
(In reply to Roger Checa from comment #17)
> Hi Chris,
> Sorry, I should have give you the trick.
> 3 commands root :
> 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
> Good luck

Thx a lot!
A.M.

CC: (none) => alemmiv

Comment 25 Aurelien Oudelet 2021-05-13 20:16:44 CEST
*** Bug 28912 has been marked as a duplicate of this bug. ***

CC: (none) => unruh

Comment 26 Aurelien Oudelet 2021-05-13 20:16:56 CEST
*** Bug 28653 has been marked as a duplicate of this bug. ***
Comment 27 w unruh 2021-05-13 21:19:40 CEST
This bug does not show up in a search  on bugzilla for google earth or google-earth which was why I reported it in 28912. It is probably because it is marked Invalid. It is NOT invalid. Not being able to find this report means that people also cannot find the solution (which also works for me). (Ie, this is a meta-bug report)
Comment 28 Aurelien Oudelet 2021-05-13 21:21:56 CEST
(In reply to Roger Checa from comment #17)
> Hi Chris,
> Sorry, I should have give you the trick.
> 3 commands root :
> 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
> Good luck

(In reply to w unruh from comment #27)
> This bug does not show up in a search  on bugzilla for google earth or
> google-earth which was why I reported it in 28912. It is probably because it
> is marked Invalid. It is NOT invalid. Not being able to find this report
> means that people also cannot find the solution (which also works for me).
> (Ie, this is a meta-bug report)

Changing it to WORKSFORME.

Resolution: INVALID => WORKSFORME

Aurelien Oudelet 2021-05-13 21:22:17 CEST

Keywords: (none) => FOR_ERRATA8
CC: (none) => fri

Comment 29 w unruh 2021-05-13 21:31:46 CEST
Note this trick also works for google-earth-pro-stable-7.3.2.5776-0
and I suspect other versions as well.
Comment 30 Dave Hodgins 2021-05-13 23:54:12 CEST
Changing it back to invalid as it's not a Mageia package.

Bugzilla search only shows open bugs by default. If you want to find closed
bugs add the keyword ALL.

Putting "ALL google-earth" (without the quotes) shows all 26 bugs that reference
google-earth.

CC: (none) => davidwhodgins
Resolution: WORKSFORME => INVALID

Comment 31 Morgan Leijström 2021-05-14 00:02:02 CEST
Mid air collision.

I was too pondering to not add it.

But as it is rather frequent asked both here in bugzilla and in forum, and if installed on mga7 it breaks on upgrade, so i went ahead.

A added to https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues

pointing users to our https://wiki.mageia.org/en/Google_Earth which already describes how to install it on mga8.

Resolution: INVALID => WORKSFORME
Keywords: FOR_ERRATA8 => IN_ERRATA8

Comment 32 Morgan Leijström 2021-05-14 00:03:45 CEST
did not mean to change from invalid

Resolution: WORKSFORME => INVALID

Comment 33 Dave Hodgins 2021-05-14 00:41:33 CEST
Note that the resolution has no impact on having the bug show up in bug searches.

What matters for default bugzilla searches is only if the bug is open or closed.

The keyword ALL must be included in the search request to show closed bugs.
Comment 34 w unruh 2021-05-14 01:23:13 CEST
In the wiki, the last sentence of 

-------
Install
Go to the location you saved google-earth-stable_current_*.rpm. Right click the file and select program installer, or use urpmi from command line. If you try to launch Google Earth now, you might get a segmentation fault. To correct this, as root:

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
If the files do not exist, you should install these packages.

-------------------
seems to be misleading, since, libssl.so.1.0.0 and libcrypt.so.1.0.0 are part of the Google-Earth-Pro package not some other packages so it is not clear what "you should install these packages" means. They are supplied by the Google Earth package.
Comment 35 Dave Hodgins 2021-05-14 02:09:36 CEST
I've removed the line about installing packages as libssl.so.1.1 and
libcrypto.so.1.1 are provided by the package libopenssl1.1 which is indirectly
required by basesystem-minimal.
Comment 36 w unruh 2021-05-14 02:37:33 CEST
It is the libcrypto.so.1.1 from the package libopenssl1.1 that, I believe, causes the crash. google-earth-pro looks for libcrypt.so.1.1 and if it is not in /opt/google/earth/pro, it uses the one from the OS (ie from libopenssl1.1) and crashes with a segfault. If one points libcrypt.so.1.1 in /opt/google/earth/pro to libcrypt.so.1.0.0 in the same place, google-earth-pro works. So there is some serious incompatibilty between libcrypto.so.1.1 from libopenssl1.1 and google-earth. Why google would supply libcrypto.so.1.0.0 when what they want and look for is libcrypto.so.1.1, I have no idea.
Comment 37 Dave Hodgins 2021-05-14 03:07:57 CEST
You're correct.

google-earth is calling functions that the /etc/ld.so.cache says are found
in the 1.1 libraries.

By creating the symlinks in the /opt directory, the dynamic linker loads the
old versions of the libs that don't have the latest security fixes instead
of the system supplied versions that have them.
Comment 38 w unruh 2021-05-14 04:15:47 CEST
Except that the system supplied version of libcrypto causes google-earth (or the libcrypto library) to segfault. Ie it is not clear whether the bug is in google-earth or is in libcrypto (which is a Mageia supplied library).
I keep refering to libcrypto, because if I only put the link to libcrypto in opt/google/earth/pro google earth does not segfault).
Comment 39 Roger Checa 2021-05-15 20:30:41 CEST
Recently, after some updates, it was impossible to open "dolphin" and/or "kwrite" as root.
Erasing the link "libssl" in "/opt/google/earth/pro/" allows newly to open these apps, and the good news is that Google-Earth" goes on working!
If it may help someone...
Comment 40 w unruh 2021-05-15 21:04:13 CEST
It is libcrypto that causes the problems with google-earth-pro, not libssl as I mentioned. So the fact that google earth continues to work with the link for libssl not there is not surprizing. On the other hand, unless someone purposely put /opt/google/earth/pro permanantly into LD_LIBRARY_PATH (a bad idea since many of the libraries in there are old, possibly insecure, libraries) the system should never see the link when opening kwrite or dolphin. That link is set up especially for running google-earth-pro in the script /bin/google-earth-pro just for running google earth, is not exported so even its children should not see the links, never mind its parents or cousins.
Comment 41 Morgan Leijström 2021-05-16 10:48:09 CEST
Please update our wiki per best knowledge :)
Comment 42 Dave Hodgins 2021-05-16 18:34:05 CEST
https://wiki.mageia.org/en/Google_Earth#Install is correct.

The rest of the above discussion is about why it's necessary, but not of
interest to most users.
Comment 43 w unruh 2021-05-16 19:15:56 CEST
Well, while it IS necessary to put in the link for libcrypt0, it does not seem to be necessary, and Comment 39 suggests that the link for libssl breaks things. I have no idea how a link in /opt/google/earth/pro, which is not in the usual set of paths searched, could break other programs, unless someone deliberately put /opt/google/earth/pro into LD_LIBRARY_PATH, that report by Checa needs at least to be considered. My, admittedly brief, tests, showed that there only needs to be link for libcrypto.so.1.1 and not for libssl.so.1.1

Note that there is no reason to permanantly put /opt/google/earth/pro into LD_LIBRARY_PATH. Teh script /bin/google-earth-pro puts it in for running google earth pro.

The necessity of that link  also suggests it is is some change in libcrypto from 1.0.0 (or even 1.1.0 in Mageaia7) which introduced, or at least triggered, the bug in running google earth.

Thus, for fear of introducing other incompatibilies, the wiki should only have the minimum changes needed to make google earth pro run, namely the link for libcrypto. I think that is what Leijstroem means.
Comment 44 Dave Hodgins 2021-05-16 19:58:54 CEST
https://wiki.mageia.org/en/Google_Earth#Install does not mention LD_LIBRARY_PATH,
so the changes only impact google-earth, not other applications.

comment 39 makes no sense, so leaving the link for libssl in the wiki unless
that problem can be recreated by others with default configurations and debugged.
Comment 45 Roger Checa 2021-05-16 21:18:33 CEST
@ Dave,

My config was working perfectly untill this update :
rpm -qa --last
lib64udev-devel-246.13-2.mga8.x86_64 mar. 04 mai 2021 19:24:58
kernel-userspace-headers-5.10.33-1.mga8.x86_64 mar. 04 mai 2021 19:24:58
systemd-246.13-2.mga8.x86_64 mar. 04 mai 2021 19:24:57
kernel-firmware-nonfree-20210426-1.mga8.nonfree.noarch mar. 04 mai 2021 19:24:57
kernel-desktop-5.10.33-1.mga8-1-1.mga8.x86_64 mar. 04 mai 2021 19:24:54
kernel-desktop-latest-5.10.33-1.mga8.x86_64 mar. 04 mai 2021 19:24:53
iwlwifi-firmware-20210426-1.mga8.nonfree.noarch mar. 04 mai 2021 19:24:53
cpupower-5.10.33-1.mga8.x86_64 mar. 04 mai 2021 19:24:53
rtlwifi-firmware-20210426-1.mga8.nonfree.noarch mar. 04 mai 2021 19:24:52
ralink-firmware-20210426-1.mga8.nonfree.noarch mar. 04 mai 2021 19:24:52
radeon-firmware-20210423-1.mga8.nonfree.noarch mar. 04 mai 2021 19:24:52
nss-myhostname-246.13-2.mga8.x86_64 mar. 04 mai 2021 19:24:52
lib64udev1-246.13-2.mga8.x86_64 mar. 04 mai 2021 19:24:52
lib64systemd0-246.13-2.mga8.x86_64 mar. 04 mai 2021 19:24:52
ldetect-lst-0.6.26.3-1.mga8.x86_64 mar. 04 mai 2021 19:24:52
kernel-desktop-devel-5.10.33-1.mga8-1-1.mga8.x86_64 mar. 04 mai 2021 19:24:51
kernel-desktop-devel-latest-5.10.33-1.mga8.x86_64 mar. 04 mai 2021 19:24:50"""

...was applied, causing "dolphin" and "kwrite" not starting in root!
Is it of "no sense" to report it ?

By the way => you will never find other users using "Google-Earth" with "default configuration" => as it is necessary to modify the / when creating the links in the "/opt" directory to have "G-E" working.

[rc@linux ~]$ echo $PATH
/home/user/.local/bin:/home/user/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/usr/lib64/qt5/bin:/usr/lib64/qt4/bin:/home/rc/.local/bin:/home/rc/bin
[rc@linux ~]$
Comment 46 w unruh 2021-05-16 22:26:16 CEST
Reporting it is fine. But this last explanation does not make much sense.
None of those updated packages should cause problems. And especially not cause the contents of /opt/google/earth/pro to be read for libraries. And why this should be reported in this bug report also escapes me.

running google earth does not require adding the /opt/google/pro path to PATH. The installation puts a shell script
google-earth-pro into /bin to start up google earth from the /opt installation.
I am not sure what "modify the /" means.
 
It is not clear what your PATH was supposed to show us.
Comment 47 Dave Hodgins 2021-05-16 22:31:30 CEST
I'm not saying it makes no sense to report it, just that it makes no sense that
having libssl present in /opt/google/earth/pro/ would impact dolphin, unless
something else has been done to cause kde to be using that directory to search
for libs when loading google-earth. Something other than what's in the wiki
for getting google-earth to run.

As it has nothing to do with getting google-earth to run, it should be reported
in a new bug if it can be be recreated, and include any changes manually made
to /etc/ld.so.conf or files it loads, and indicate how you are running them as
root (using sudo, su, su -, kdesu, etc.).
Comment 48 Dave Hodgins 2021-11-12 06:08:00 CET
*** Bug 29650 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.