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 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.
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.
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 5/13/21 9:01 PM, William Unruh wrote:Come to think of it, it may have been Mandriva that offered to install
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 bugzillaYes, it's an upstream problem that will have to be addressed by Google.
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. >>>
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 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 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 bugzillaYes, it's an upstream problem that will have to be addressed by Google.
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. >>>
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?
When did the mainline transformation from libcrypto 1.0.0 to 1.1 occur?
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.
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?
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
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?
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
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.
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 16:32:36 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,190 |
Messages: | 5,327,108 |