Ubuntu
kdegraphics package

sumbol lookup error when launching okular

Asked by Bernard François

Binary package hint: kdegraphics

I just installed okular in ubuntu 9.04 (under gnome).

When I run it, nothing happens.

When I run it from a terminal, I get the following output:

ber@ubuntu:~$ okular
okular: symbol lookup error: /usr/lib/libQtDBus.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEv

Note that I had a similar issue with the subcommander package yesterday; there the same undefined symbol occurs in the /usr/lib/libQtNetwork.so.4 library.

Note that I used the 'ubuntu-bug' tool to report this bug, and that it automatically suggested to report this bug for the 'kdegraphics' package instead of the 'okular' package.

I seems like there's an incompatibility between the version of Qt in the repositories and some packages using Qt.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: okular 4:4.2.2-0ubuntu2
ProcEnviron:
 PATH=(custom, no user)
 LANG=C
 SHELL=/bin/bash
SourcePackage: kdegraphics
Uname: Linux 2.6.28-6-386 i686

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu kdegraphics Edit question
Assignee:
No assignee Edit question
Solved by:
Terence Simpson
Solved:
Last query:
Last reply:

This question was originally filed as bug #390200.

Revision history for this message
Bernard François (bernardfrancois-gmail) said : 		#1
Revision history for this message
Terence Simpson (tsimpson) said : 		#2

This is most likely due to you having another third-party install of the Qt4 libraries installed. Can you post the output of the following console commands:

which okular

ldd $(which okular)

Revision history for this message
Bernard François (bernardfrancois-gmail) said : 		#3

Here you go... (see attachment).

I don't think I ever installed version of the Qt4 libraries by downloading and installing a .deb or other package, or by compiling from source.

Revision history for this message
Jonathan Thomas (echidnaman) said : 		#4

It seems a local Qt installation has crept in somehow:
libQtCore.so.4 => /usr/local/lib/libQtCore.so.4 (0xb7315000)
libQtGui.so.4 => /usr/local/lib/libQtGui.so.4 (0xb6ade000)

There's nothing we can do to fix this bug, but we can turn it into a question so that you can get support. Hope everything works out for you.

Revision history for this message
Bernard François (bernardfrancois-gmail) said : 		#5

Ok. Maybe we'll still find out what caused this packages to be installed.

I see that I do have the libqtcore4 and libqtgui4 packages installed in synaptic (containing respectively /usr/lib/libQtCore.so.4 and /usr/lib/libQtGui.so.4).

I would like to find out with which package the local versions of these libraries came. Is it possible to know with which package a certain file was installed? (I know it is, by manually viewing the contents of installed packages, but I'm hoping that there's a faster way).

I just checked the "Installed (local or obsolete)" category in synaptic, but there are no packages that installed these files there.

I also wonder why okular is using the locally modified version of Qt, and not the 'official' one (as I just installed okular from the repositories). Isn't that a bug? The problem wouldn't have been there if the okular package just relied on the "official" Qt package (which would seem logical, as they're both from the ubuntu repositories).

I guess there must be a list of folders where dynamic libraries are to be found, similar to the $PATH environment variable. I tried to find such an environment variable, but without succes.

Revision history for this message
Terence Simpson (tsimpson) said : 		#6

You can see if a (.deb) package installed the libraries with "dpkg -S libQtCore.so.
There is no way for okular to know what is "official" and what's not, the binary just says it requires "libQtCore.so.4", it doesn't care how/where the system finds it.
There is an environment variable that can control the paths the linker searches, this is $LD_LIBRARY_PATH, but the default paths are set in /etc/ld.so.conf and the .conf files in /etc/ld.so.conf.d/

Revision history for this message
Terence Simpson (tsimpson) said : 		#7

Sorry, that command should be "dpkg -S libQtCore.so.4"

Revision history for this message
Bernard François (bernardfrancois-gmail) said : 		#8

According to the output of the dpkg -S command, the file in the /usr/local/lib directory doesn't belong to any package.

I renamed the two library files in question in the /usr/local/lib, so they can't be used any more (also keeping a backup, in case it would break something).

The $LD_LIBRARY_PATH environment variable is empty here (also when logged in as root), but maybe this is the default in Ubuntu.

The /usr/local/lib path indeed appears in the /etc/ld.so.conf.d/libc.conf file.

I'm really wondering where this local Qt installation came from. Is there a way to remove all stuff like this from my system?

Revision history for this message
Best Terence Simpson (tsimpson) said : 		#9

If you can't find what installed the libraries then you'll just have to remove/rename the files manually. By default there are no files in /usr/local (there are some default directories, but there should be no files), so everything under there is not from any Ubuntu/Kubuntu package.
/usr/local/lib is indeed supposed to be in /etc/ld.so.conf.d/libc.conf, so that's normal, as is $LD_LIBRARY_PATH being empty.
I'm not sure how anything got into /usr/local/lib without a .deb installing it, perhaps "dpkg -S usr/local/lib/" (no leading '/') will show something. If not then you'll have to handle it manually.

Revision history for this message
Bernard François (bernardfrancois-gmail) said : 		#10

Thanks for the info!