Google Earth 5.0, Ubuntu 9.04 (Jaunty Jackalope) – symbol lookup error: libssl.so.0.9.8, undefined symbol: EVP_idea_cbc, libcrypto.so.0.9.8 bug

I have tried to install Google Earth on Ubuntu 9.04 (Jaunty Jackalope) today and I came across a simple bug.

After installation, Google Earth was not able to communicate using SSL. It gave me this error message:

/usr/lib/googleearth/googleearth-bin: symbol lookup error: /usr/lib/googleearth/libssl.so.0.9.8: undefined symbol: EVP_idea_cbc

The simple bug-fix is to rename/copy libcrypto.so.0.9.8 shared library into libcrypto.0.9.8, as I have found only on some French websites.
Use sudo if you’re not logged in as root. You can also probably use mv instead of cp. You can run for example these commands:

root@v-teq-laptop:~$ cd /usr/lib/googleearth/
root@v-teq-laptop:/usr/lib/googleearth$ cp libcrypto.so.0.9.8 libcrypto.0.9.8

Everything should run now, just enjoy Google Earth

DDD (gdb): No source: ../sysdeps/x86_64/elf/start.S: No such file bug; Missing XKeysymDB file bug

I came across a strange bug, or better said, strange behavior of ddd today. I have tried to debug my program and I have got this error dialogue:

DDD: No source
/home/v-teq/…/sysdeps/x86_64/elf/start.S: No such file or directory

Missing XKeysymDB file

I have tried to find out where was the problem:

v-teq@v-teq-laptop:~$ ddd --check-configuration
Checking for XKeysymDB... (none)
Warning: The `XKeysymDB' file is not in the default X file search path.
    If ddd was not compiled on this machine, ddd
    may not run properly (lots of warnings for unknown keysym names).
    and install it into your X project root (typically `/usr/lib/X11')
    or have the XKEYSYMDB environment variable point at it.

But as you can see, I found another error message that was ddd printing out – it couldn’t find XKeysymDB file. The solution was quite easy – only to find the XKeysymDB file in my /usr directory, because default /usr/lib/X11 path doesn’t exist anymore on my Debian based machine.

v-teq@v-teq-laptop:~$ find /usr -name XKeysymDB
/usr/share/X11/XKeysymDB

So the answer was /usr/share/X11/XKeysymDB in my case.

Now it’s easy to set environment variable and get ddd working again:

v-teq@v-teq-laptop:~$ XKEYSYMDB=/usr/share/X11/XKeysymDB ddd --check-configuration
Checking for XKeysymDB... /usr/share/X11/XKeysymDB

You can set variable pernamently of course (or you can echo this line into your ~/.bashrc or such file).
For sh, ksh or bash:

export XKEYSYMDB="/usr/share/X11/XKeysymDB"

For csh:

setenv XKEYSYMDB "/usr/share/X11/XKeysymDB"

DDD: No source: ../sysdeps/x86_64/elf/start.S

Now back to the first problem – error dialogue that said I didn’t compiled debugging information to my executables, so debuggers (ddd, gdb) weren’t able to use symbols from source files.

Take care if you have compiled your binary files (executables or libraries) really with debugging information (eg. -g option in gcc). My problem was, that my Makefile created executables from libraries with -g option, but libraries themselves were compiled without this option automatically (there was no rule to make *.o files in Makefile).

So my advice is to double check your Makefile, or command line if you’re compiling project manually, if you have really set the -g option. For example:

gcc -g -o main main.c

Or if you want to create *.o file before linking to final executable, don’t forget to check -g option in both cases:

gcc -g -c -o main.o main.c
gcc -g -o main main.o

You can also add something like that to your Makefile to compile *.o files with -g debugging option automatically:

CC=gcc
CFLAGS=-g
 
%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

Emerge Portage – Multiple package instances within a single package resulting slot conflict

As usual at least once a month, I came across a bug in The Portage Tree of Gentoo Linux.

root@v-teq-laptop $ emerge -Dup world # --deep --update --pretend
 
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
 
sys-libs/readline:0
 
('ebuild', '/', 'sys-libs/readline-5.2_p13', 'merge') pulled in by
=sys-libs/readline-5* required by ('ebuild', '/', 'dev-lang/ghc-6.8.2', 'merge')
(and 16 more)
 
('installed', '/', 'sys-libs/readline-6.0', 'nomerge') pulled in by
sys-libs/readline:0 required by world
sys-libs/readline required by system
sys-libs/readline required by world
(and 13 more)
 
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.
 
For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.

To get rid of such package conflict you have to add package name into package.mask file. And even better is to put there only one version of those conflicted packages.
There you can see example solution of this kind of bug:

echo ">=sys-libs/readline-6.0" >> /etc/portage/package.mask

Firefox ‘already running’ bug -> delete .parentlock file

I came across a strange bug today, using CentOS Linux. The whole system suddenly froze up and I had to restart the whole computer (it was not even possible to change to any TTY using CTRL+ALT+F[0-8] or restart X by pushing CTRL+ALT+BACKSPACE). But after rebooting I couldn’t start Mozilla Firefox browser.

Error dialogue during a Firefox startup:

Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.

The solution is to delete .parentlock file in your firefox home directory.

$ rm ~/.mozilla/firefox/<session>.default/.parentlock
# substitute <session> with your default session (or '*' should probably work too)