The splash screen pops up, CPU goes to 100% and stays there, until I kill it. I saw this before and thought it was bug 158701, but that is listed as fixed and this isn't. eselect opengl list Available OpenGL implementations: [1] ati * [2] xorg-x11 x11-drivers/ati-drivers-8.32.5 emerge --info Portage 2.1.2-r9 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.18-gentoo-r6 x86_64) ================================================================= System uname: 2.6.18-gentoo-r6 x86_64 Mobile AMD Athlon(tm) 64 Processor 3700+ Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 05 Mar 2007 18:00:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/readers/usb/ifd-ccid.bundle/Contents /usr/share/X11/xkb /usr/share/config /usr/share/genkernel/generic /usr/share/genkernel/x86_64" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=k8 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://mirrors.tds.net/gentoo http://mirror.datapipe.net/gentoo" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 berkdb bitmap-fonts bzip2 cdr cli cracklib crypt cups dri eds emboss encode esd expat f77 fam firefox foomaticdb fortran gdbm gif glut gnome gpm gstreamer gtk gtk2 gtkhtml hal iconv imagemagick imlib ipv6 isdnlog java jpeg kde lcms lzw lzw-tiff midi mng mozilla mp3 mpeg ncurses nls nptl nptlonly nsplugin opengl oss pam pcre pcsc-lite pdf perl png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb vorbis xine xorg xpm xv zlib" ALSA_CARDS="atiixp" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="vga fglrx" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
You'll need to complain to Google, not our problem.
my brother has the same problem and I have no solution to it. Since both google and ati are closed source we have little chance of fixing it ourselves :( If you got any idea how to fix it please reopen. Please go to google and ati to complain
There does seem to be a workaround. See this thread http://bbs.keyhole.com/ubb/showflat.php?Cat=0&Board=SupportGELinux&Number=620003&page=3&fpart=2 Google earth works with libGL.so.1.2 (32 bit) from ati-drivers-8.27.10-r1 but not any latter version. It looks for libraries in /opt/googleearth first, so you can have googlearth (and only googleearth) use the old library by placing it in that directory (as libGL.so.1). I have been using it for a while and it appears to work fine for me. I would have posted this sooner, but I hadn't verified the identity of the file I was using (now I have). If there is no objection, I could write a patch to the ebuild that puts the right file in the right place, ether checking if it is needed, or if it is too hard to tell for sure, controlled by a use flag.
I notice that there is a new version. I will try that first, since an upstream solution is always preferred.
well, feel free to contribute a patch :)
Created attachment 133802 [details, diff] implements workaround The new version from upstream still has the same problem. Here is a patch to googleearth-4.2.198.2451.ebuild. If emerged with the new fixati use flag, it downloads and installs the required file from ati-drivers-8.27.10. It gets it from the same url as the ati-drivers ebuild. If it detects a suspect version, it prints a warning. I can't test enough configurations to be sure when it is required, or if it may sometimes do harm, so I don't install the "fix" automatically.
*** Bug 198406 has been marked as a duplicate of this bug. ***
can you give me a proper unified dif (diff -u) please and use proper indenting?
Created attachment 137067 [details, diff] implements workaround Is this any better?
(In reply to comment #6) >[...] > The new version from upstream still has the same problem. [...] For me, the 8.42.3 version actually solved the problem (once I finally got all of the links correctly created for the libGL files), though I ended up reverting anyway due to other problems using ati-drivers-8.42.3. On the other hand, the workaround involving the older ATI libGL.so (at least in previous versions of the driver) caused Google Earth to force itself into unbearable "Software Rendering" mode on my system (amd64) rather than really solving the problem. I think it's worth trying the new "7.11" ("8.433" in Portage?) as well, once the SONAME problem (see bug#199633) is solved. For what the opinion of a random Gentoo user is worth...
>> The new version from upstream still has the same problem. > For me, the 8.42.3 version actually solved the problem (once > I finally got all of the links correctly created for the > libGL files) I was referring to a (then) new googleearth version. The new ati-drivers version doesn't work at all for me yet (I have been burned by hand added sym-links before, and need to test on a pure install anyway). If it solves the problem, I will ether edit the patch to only cover the affected versions, or just mark it fixed. If it doesn't help, I will test the patch on the new version and report back here.
Fixed in ati-drivers-8.433. The workaround in my proposed patch *breaks* googleearth with the new version of ati-drivers, so it would be much more trouble than it is worth just to fix older versions.
(In reply to comment #12) > Fixed in ati-drivers-8.433. Does that mean that googleearth should be expected to work now? I checked my versions -- I currently have googleearth-4.2.198.2451 and ati-drivers-8.433. My video adapter is ATI Radeon 9600. And when trying to start googleearth I am getting "error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory".
> And when trying to start googleearth I am getting > "error while loading shared libraries: libGL.so.1: cannot > open shared object file: No such file or directory". That's bug#199633, glxgears does the same thing. Look at that bug for a fairly simple workaround.
*** Bug 211912 has been marked as a duplicate of this bug. ***
