# HOWTO: Make Google Earth use system libraries

## Etal

Why, you ask?

When I updated Google Earth to version 5, I found the fonts look awful. So, I decided to link replace the Qt libs that come with Google Earth with those that I have installed. This resulted in nice, clean fonts.

Other reasons why you might want to do that could be because:

- you want to Zomg-Optimize!!1

- you're bored

- you really need those extra 19 MB

To do that, I wrote this script:

```
#!/bin/bash

cd /opt/googleearth

find . -maxdepth 1 -type f -regex '^\./lib.*so\..*' -printf '%f\n' | while read lib

do

        echo "Searching for $lib ..."

        find /lib /usr/lib/ -name "$lib" \

                -exec echo -n "Replacing $lib with {} ... " \; \

                -exec ln -fs '{}' "$lib" \; \

                -exec echo "OK" \;

done
```

What it does is it searches for each library in Google Earth's directory and finds their counterpart in /usr/lib. It then replaces Google's library with a symlink to the system library.

For me, it works like a charm. If it doesn't work, simply re-emerge googleearth, and it will all be back to normal.

Have fun!

Edit: A little semi-related tidbit I found - if you don't like the Qt style it comes with by default, you can change it in /opt/googleearth/googleearth, on line 48: Just change "-style=cleanlooks" to "-style=oxygen"

Small Edit: Added /lib to search path to get libz.so

----------

## poly_poly-man

before I try it, does it work with amd64?

----------

## Etal

That I can not answer since I never used AMD64. Since Google Earth is apparently 32-bit, my guess would be no, because you probably don't have those 32-bit libs.

----------

## szczerb

 *AM088 wrote:*   

> That I can not answer since I never used AMD64. Since Google Earth is apparently 32-bit, my guess would be no, because you probably don't have those 32-bit libs.

 Yeah, we do - there is a bunch of emul-linux-x86-* packages.

----------

## mv

This tip is great. For amd64 it does not save much space, but in principle the approach is possible. The only problem I had was that the openoffice-bin libraries cannot replace the google libs (I do not know why).

To make the whole approach a bit more generically (and let it work also for the next emerge of googleearth), you can alternatively put the following code into /etc/portage/env/x11-misc/googleearth

```

mv_ln_libs () {

   case "${MV_NO_LN_LIBS}" in ''|false|0|no) true;; *) return 0;; esac

   local pathlist="/lib /usr/lib"

   use amd64 && {

      test -d /lib32 || test -d /usr/lib32

   } && pathlist="/lib32 /usr/lib32"

   local i j k l

   l=''

   for i

   do

      test -f "${i}" || continue

      j="${i##*/}"

      for k in ${pathlist}; do

         [ -n "$(find "${k}" -name openoffice -prune -o \

            -name "${j}")" ] || continue

         l="${l} ${j}"

         find "${k}" -name openoffice -prune -o \

            -name "${j}" -exec \

            /bin/ln -vsfn -- '{}' "${i}" ';' -quit

         break

      done

   done

   [ -z "${l}" ] && return

   ewarn

   ewarn "${PORTAGE_CONFIGROOT%/}/etc/portage/env/${CATEGORY}/${PN}*"

   ewarn "The following libs have been linked symbolically:"

   ewarn ${l}

   ewarn "The package might not depend on these libs, so this may break."

   ewarn "If the libs change, a reemerge of the package might be needed."

   ewarn "Set MV_NO_LN_LIBS=true during emerge to skip this hack."

   ewarn

}

post_pkg_preinst() {

   mv_ln_libs "${D}"/opt/googleearth/lib*.so.* "${D}"/opt/googleearth/plugins/*/lib*.so

}
```

 It should be obvious how to change the code for other binary packages.

As usual for such hacks: If somethings breaks you keep the pieces. Do not report a bug for googleearth unless you have reemerged with MV_NO_LN_LIBS set.Last edited by mv on Sun Feb 22, 2009 8:55 pm; edited 1 time in total

----------

## toralf

Why you do not include in /usr/bin/googleearth sth. like 

```
LD_LIBRARY_PATH="/usr/lib:${LD_LIBRARY_PATH}"
```

?

----------

## Etal

 *toralf wrote:*   

> Why you do not include in /usr/bin/googleearth sth. like 
> 
> ```
> LD_LIBRARY_PATH="/usr/lib:${LD_LIBRARY_PATH}"
> ```
> ...

 

I haven't tried that. Does it work if you delete the libraries that my script finds?

----------

## toralf

 *AM088 wrote:*   

> Does it work if you delete the libraries that my script finds?

 Try it yourself by doing sth. like:

```
cd /opt/googleearth/

LD_LIBRARY_PATH="/usr/lib:`pwd`"

ldd libapiloader.so 
```

and look at the output.

----------

## Etal

 *toralf wrote:*   

>  *AM088 wrote:*   Does it work if you delete the libraries that my script finds? Try it yourself by doing sth. like:
> 
> ```
> cd /opt/googleearth/
> 
> ...

 

I reemerged googleearth and tried playing around with the LD_LIBRARY_PATH inside of /usr/bin/googleearth as well as in /opt/googleearth/googleearth, but it doesn't seem to work - Google Earth continues to start with the ugly fonts, meaning it still uses its bundled libraries. Also, the output of ldd is the same whether I set the variable or not (it points to /usr/lib).

So my solution of removing those libraries seems to work better for now  :Wink: 

----------

## mv

 *toralf wrote:*   

> Why you do not include in /usr/bin/googleearth sth. like 
> 
> ```
> LD_LIBRARY_PATH="/usr/lib:${LD_LIBRARY_PATH}"
> ```
> ...

 

IIRC (no time to check in the moment), the paths in LD_LIBRARY_PATH are not search recursively, so you would have to include all subdirs (in particular, the qt-subdir(s?)) as well. However, I do not see the advantage: Patching a script and removing unneded libraries or replacing them by symlinks should be about the same in effort and effect.

----------

## toralf

 *mv wrote:*   

>  the paths in LD_LIBRARY_PATH are not search recursivel

 That's correct, my intention was rather related to state out, that IMHO the use of an environment variable is better compared to hard/soft links within an emerged package directory.

----------

## xiber

Hey AM088, thanks for the tip. Just installed googleearth. Fonts now look alot better.

But...

The blue square popup photographs still popup, but minus the photographs.

----------

## albright

fonts do look better after this hack, but instead of photos appearing

when I click on the little box-things, I get little question mark icons.

A re-emerge fixed that but of course brought back the ugly font.

----------

## xiber

To get good looking fonts, at least in my case, only libQtCore.so.4 and libQtGui.so.4 need to be replaced in

/usr/opt/googleearth, but subsutiting libQtCore.so.4 causes popup photos to be replaced by blue squares.

----------

## musv

Replacing that libs with the system ones occures a 

```
./googleearth-bin: error while loading shared libraries: libQtCore.so.4: wrong ELF class: ELFCLASS64
```

Is Google-Earth only 32bit?

Update: Ok reading again that thread: Google earth is only 32bit

 *szczerb wrote:*   

>  *AM088 wrote:*   That I can not answer since I never used AMD64. Since Google Earth is apparently 32-bit, my guess would be no, because you probably don't have those 32-bit libs. Yeah, we do - there is a bunch of emul-linux-x86-* packages.

 

At least here app-emulation/emul-linux-x86-qtlibs installed only qt3-libs. Afair Google Earth is qt4-based. I had the same problem with opera, which didn't start as 64bit version.

```
* Contents of app-emulation/emul-linux-x86-qtlibs-20080316:

/usr

/usr/kde

/usr/kde/3.5

/usr/kde/3.5/lib32

/usr/kde/3.5/lib32/libDCOP.so -> libDCOP.so.4.2.0

/usr/kde/3.5/lib32/libDCOP.so.4 -> libDCOP.so.4.2.0

/usr/kde/3.5/lib32/libDCOP.so.4.2.0

/usr/kde/3.5/lib32/libkdecore.so -> libkdecore.so.4.2.0

/usr/kde/3.5/lib32/libkdecore.so.4 -> libkdecore.so.4.2.0

/usr/kde/3.5/lib32/libkdecore.so.4.2.0

/usr/kde/3.5/lib32/libkdefx.so -> libkdefx.so.4.2.0

/usr/kde/3.5/lib32/libkdefx.so.4 -> libkdefx.so.4.2.0

/usr/kde/3.5/lib32/libkdefx.so.4.2.0

/usr/qt

/usr/qt/3

/usr/qt/3/lib32

/usr/qt/3/lib32/libqt-mt.so -> libqt-mt.so.3

/usr/qt/3/lib32/libqt-mt.so.3 -> libqt-mt.so.3.3

/usr/qt/3/lib32/libqt-mt.so.3.3 -> libqt-mt.so.3.3.8

/usr/qt/3/lib32/libqt-mt.so.3.3.8

/usr/qt/3/lib32/libqt.so -> libqt-mt.so

/usr/qt/3/lib32/libqt.so.3 -> libqt-mt.so.3

/usr/qt/3/lib32/libqt.so.3.3 -> libqt-mt.so.3.3

/usr/qt/3/lib32/libqt.so.3.3.8 -> libqt-mt.so.3.3.8

/usr/qt/3/lib32/libqui.so -> libqui.so.1

/usr/qt/3/lib32/libqui.so.1 -> libqui.so.1.0

/usr/qt/3/lib32/libqui.so.1.0 -> libqui.so.1.0.0

/usr/qt/3/lib32/libqui.so.1.0.0
```

Is there a way to get emul-linux-qtlibs for qt4?

----------

## strobeam

The pictures in the panoramio-windows are missing because not all QT4-libs are replaced. The libs for displaying pictures are located under

```
/opt/googleearth/plugins/imageformats
```

and have to be linked to the corresponding libs under

```
usr/lib/qt4/plugins/imageformats/
```

Perhaps these libs can be included into the script too, but I don't see how to do it now.

----------

## mv

 *strobeam wrote:*   

> Perhaps these libs can be included into the script too, but I don't see how to do it now.

 

I changed my suggestion (the script for /etc/portage/env/x11-misc/googleearth in a later posting) correspondingly.

Now the approach in this script is even more generically: You can perhaps even pass in addition "${D}"/opt/googleearth/lib*.so (or at least a subset thereof) in the call to mv_ln_libs to save even more space by replacing more libs, but I didn't try whether this (or with which libs) this works.

----------

## Calvin721

 *strobeam wrote:*   

> The pictures in the panoramio-windows are missing because not all QT4-libs are replaced. The libs for displaying pictures are located under
> 
> ```
> /opt/googleearth/plugins/imageformats
> ```
> ...

 

OK, I got back panoramio pictures and also placemark icons back. 

But, my own places and tracks are not located where they are supposed to be. Also, other placemarks are dislocated. When I use the libraries shiiped with GE, there are no problems. Any hints?

My QT version: qt-gui-4.4.2-r1 (split ebuilds)

Regards,

Stefan

----------

## Hyper_Eye

Has there been any progress on this on the 64-bit side? I checked and the qt 32-bit libs are still qt3. If 32-bit qt4 libs were provided we would be good to substitute those libs and have fonts we can actually read right?

----------

## Hoek

After running the script and starting googleearth:

```

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./googleearth-bin)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libgoogleearth_lib.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libbase.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libge_net.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libgeobase.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libapiloader.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libauth.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libcommon.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libcomponentframework.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libmoduleframework.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./libport.so)

./googleearth-bin: ./libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by ./librender.so)
```

I'm on 32bit.

----------

## HMC

This one is a keeper. Thanks AM008

Running ~x86 KDE4.2, qt4.5, X11 overlay, 2.6.29... on i915 mobile a lot of stuff is broken. GE was totally smashed and this script proved to be a really quick fix for the bulk of its problems. 

Cheers

----------

## golding

AM088, thankyou, thankyou, thankyou   :Very Happy: 

Ran the script and the GoogleEarth app fonts are now clean and crisp, unlike the rendering from the old font libs, they made it virtually unreadable.  

Actually, I lie, they were unreadable, to the point that I had to use Google Maps in Firefox as GE was basically unusable with the fonts rendered as they were.

And all without any of the problems others seem to have had.

Has anybody thought to have this as a patch for the ebuild, perhaps with a use flag?   :Cool: 

----------

## billydv

I have tried copying libs from an X86 machine to my amd64 machine and no matter what I copy it still doesn't work. Has anyone reached a fix for an ~amd64 box?

----------

## Apopatos

 *billydv wrote:*   

> I have tried copying libs from an X86 machine to my amd64 machine and no matter what I copy it still doesn't work. Has anyone reached a fix for an ~amd64 box?

 

Yup, see here:

https://forums.gentoo.org/viewtopic-t-764144.html

----------

## MalleRIM

Simply deleting the libraries will force googleearth to use the system libraries. There is no need of symlinking. But, is there a possibility to use any non-standard Qt-style such as bespin or oxygen?

----------

## Apopatos

 *MalleRIM wrote:*   

> But, is there a possibility to use any non-standard Qt-style such as bespin or oxygen?

 

I suppose it's like openoffice, so I don't think is possible.

----------

## MalleRIM

I suppose not, because

openoffice emulates qt4, to look better on qt4-based desktops

Googleearth uses qt4 and still looks ugly as hell on qt4 based desktops

----------

## irylle12

Will this work smoothly with me? I have 32-bit.. Don't want to damage some of my files that's why i ask first...

signature spam removed -- admin

----------

## jomen

@irylle12

Read MalleRIM's post on the previous page (as well as the others...) - just deleting the libs that come with googleearth wil make it use your systems libs.

It works for me (32 Bit) - and can always be undone by just reinstalling googleearth.

----------

## toralf

If I add this line to googleearth :

```
LD_LIBRARY_PATH="/lib:/usr/lib:${LD_LIBRARY_PATH}"
```

I see within my .xsession-errors at a x86 system (core2 duo) :

```
Major Version 5

Minor Version 1

Build Number 3509

Build Date Sep 17 2009

Build Time 15:19:56

OS Type 11

OS Major Version 2

OS Minor Version 6

OS Build Version 31

OS Patch Version 4

Crash Signal 11

Crash Time 1255606212

Up Time 53.4475

Stacktrace from glibc:

./googleearth-bin[0x805caa6]

[0xb7848400]

./libge_net.so(_ZN5earth3net18CurlHttpConnection20ProcessAsyncRequestsEv+0x58)[0xb5525b58]

./libge_net.so(_ZN5earth3net18CurlHttpConnection10ThreadFuncEPv+0x1d)[0xb5525b9d]

/lib/libpthread.so.0[0xb59b016f]

/lib/libc.so.6(clone+0x5e)[0xb5f67c0e]

```

therefore I'm wondering whether it's a good idea to replace the bundled libs or not ....

----------

## albright

Does anyone know why my googleearth will only run in opengl

software emulation mode??

(It makes no difference whether I use google or system libs)

this is an intel GM965/GL960 on a thinkpad x300 with

intel driver 2.9.0 and mesa 7.5.1 and xorg-server 1.6.5

TIA

----------

## toralf

 *albright wrote:*   

> Does anyone know why my googleearth will only run in opengl
> 
> software emulation mode??
> 
> (It makes no difference whether I use google or system libs)
> ...

 Probably the card, b/c w/ the same intel driver and mesa and only minor version diff in xorg-server-1.6.4 I've running a T400 (intel 915 graphics) w/o problems.

----------

## albright

I've upgraded to xorg-server-1.7.1, intel driver 2.9.1

and tried out mesa-9999 from x11 overlay

but googleearth still will only run in opengl software

emulation mode.

I also tried downloading directly from google the bin

file - no difference.

I stress that glxinfo reports that direct rendering is ON

and glxgears runs fine ... (are there any other programs

that would test the glx system - the kde desktop effects

work great FWTW)

----------

## Bircoph

 *MalleRIM wrote:*   

> Simply deleting the libraries will force googleearth to use the system libraries. There is no need of symlinking. But, is there a possibility to use any non-standard Qt-style such as bespin or oxygen?

 

Nope. Not all libs are in system default search paths. You should tamper with LD_LIBRARY_PATH. But the latter will alter *.so$ files some of them should not be altered.

----------

