[SOLVED] Perhaps a true 64 bit of Google Earth is available!
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Perhaps a true 64 bit of Google Earth is available!
From what I saw looking at Google Earth this morning, there appears to really be a pure 64 bit version available!
At least when I ran ldd on the various binaries, the versions listed were 64 bit. (This was from google-earth-stable_current_x86_64.rpm without fixing LD_LIBRARY_PATH)
4) GoogleEarth is a 32bit application only. You need to have the 32bit
compatibility packages installed to have this work on a 64bit system.
Otherwise you'll just see "no such file or directory" errors. I am aware
that Google puts a 64bits debian package out, but this is a 32bits package
with a 64bit wrapper for debian that installs multilib
I've gotten that RPM to work on my 14.0 non-multilib 64 bit system by symlinking /lib64/ld-lsb-x86-64.so.3 to /lib64/ld-2.15.so. It runs well, but with at least one missing feature: Clicking on a "there's a photo here" icon on the map generates a "[0523/014728:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler." message to stdout as well as not displaying the photo in question.
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,680
Rep:
I have found exactly the same thing using the .deb on 64 bit Debian. I do have the 32 bit libraries present but running ldd on Google Earth shows that the 64 bit libraries are now being used. I can't see the photo's either though, which is annoying.
Not relevant to it being used on Slackware but the .deb still insists that ia32-libs is installed which is odd to say the least.
I did a rpm2txz and installed Google Earth 7.1, but it dies with a "No such file or directory". I don't see any missing libraries with ldd (did the whole /opt/google/earth/free directory, and strace doesn't point to anything either. I did the LSB lib symlink thing too, so what else do I need to do to get it going?
I did a rpm2txz and installed Google Earth 7.1, but it dies with a "No such file or directory". I don't see any missing libraries with ldd (did the whole /opt/google/earth/free directory, and strace doesn't point to anything either. I did the LSB lib symlink thing too, so what else do I need to do to get it going?
Andy
Code:
ln -s /lib64/ld-2.15.so /lib64/ld-lsb-x86-64.so.3
Last edited by Richard Cranium; 05-27-2013 at 08:37 PM.
Reason: tronayne gently pointed out that I wrote the symlink backwards. It's correct *now*.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
I'm either getting totally brain-dead or there's something seriously amiss with Google-Earth (from google-earth-stable_current_x86_64.rpm made into a Slackware package with rpm2tgz).
Given:
Code:
whence -v google-earth
google-earth is a tracked alias for /usr/bin/google-earth
google-earth
/usr/bin/google-earth: line 43: ./googleearth-bin: No such file or directory
OK, go on a bug hunt. /usr/bin/google-earth is
Code:
ls -l /usr/bin/google-earth
lrwxrwxrwx 1 root root 34 May 27 10:09 /usr/bin/google-earth -> /opt/google/earth/free/googleearth*
All it does is set up ${PATH} and ${LD_LIBRARY_PATH} to /opt/google/earth/free, cd there and launch googleearth-bin (the file it "can't find").
It's there and executable, right? Sure looks that way to me anyway.
So, let's see if we can run that damn thing directly:
Code:
cd /opt/google/earth/free
PATH=${PWD}:${PATH}
LD_LIBRARY_PATH=${PWD}:${LD_LIBRARY_PATH}
echo ${PATH}
/opt/google/earth/free:.:/home/trona/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/opt/GMT/bin:/opt/netCDF/bin:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/kde4/libexec:/usr/lib64/qt/bin:/usr/share/texmf/bin:.
echo ${LD_LIBRARY_PATH}
/opt/google/earth/free:
Looks right to me.
Sitting in
Code:
/opt/google/earth/free
googleearth-bin
-ksh: googleearth-bin: not found [No such file or directory]
An, no, KornShell does not matter anymore than BASH would (and neither does the ".:" in ${PATH}).
So, log out, log back in and export the paths (just in case, who knows?):
Code:
cd /opt/google/earth/free
export PATH=${PWD}:${PATH}
export LD_LIBRARY_PATH=${PWD}:${LD_LIBRARY_PATH}
echo ${PATH}
/opt/google/earth/free:.:/home/trona/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/opt/GMT/bin:/opt/netCDF/bin:/usr/lib64/java/bin:/usr/lib64/java/jre/bin:/usr/lib64/kde4/libexec:/usr/lib64/qt/bin:/usr/share/texmf/bin:.
echo ${LD_LIBRARY_PATH}
/opt/google/earth/free:
whence -v googleearth-bin
googleearth-bin is a tracked alias for /opt/google/earth/free/googleearth-bin
And run it:
Code:
fubar-trona-/opt/google/earth/free: googleearth-bin
-ksh: googleearth-bin: not found [No such file or directory]
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Thanks... but, the symlink shown previously? Kinda backwards -- I looked to see if /lib64/ld-2.15.so was there, it was, so... I didn't actually look for /lib64/ld-lsb-x86-64.so.3 (said I was getting brain-dead). It need to be
Code:
ln -s /lib64/ld-2.15.so /lib64/ld-lsb-x86-64.so.3
The errors that are popping up are not a little better:
Code:
google-earth
[0527/140622:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses()
[0527/140625:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0527/140625:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0527/140631:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[0527/140631:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
But! Guess what shows up?
Pretty slow (for a 64K system with 8G available on Intel(R) Core(TM)2 Duo CPU E7600 @ 3.06GHz, but, what the heck, the thing seems to work (been a looonnngggg time since I've seen this bad boy).
Now I'll go remove all the symlinks I made with this:
Because I'm running something sorta current, the link was actually supposed to be "ln -s /lib64/ld-2.17.so /lib64/ld-lsb-x86-64.so.3", not 2.15. So now it works, but it's slow, the pictures don't work, the max texture size is still 4k, and I get the same runtime errors. I'm sure it will get better, because any worse would be unusable.
The lack of photos is apparently fixed by something in this thread. After skimming the thread, I think that I can live without the photos. If I *really* want to see them, I'll launch a 32 bit virtual machine and look at them there.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.