[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: KDE apps getting an extra library path



2009/6/25 Alejandro Exojo <suy@badopi.org>:
> Hi.
>
> As I usually do when a KDE release is close, I've compiled kdelibs,
> kdepimlibs, kdebase and other needed modules (akonadi and phonon, IIRC) from
> SVN's source, and I've installed it in my home directory.
>
> I just did 'cmake -DCMAKE_INSTALL_PREFIX=$KDEDIR ../../kdefoo' to set the
> source, where KDEDIR is set to $HOME/local/kde4, and a 'make install' to
> compile and install, everything as the same regular user.
>
> This is been perfectly safe since now, because the KDE installation from the
> Debian packages can't see that there is stuff in my home directory unless I
> want to. When I wanted to run an app locally installed, I sourced the
> attached script in a shell, which sets up some environment variables, run the
> program from that shell, and that's all.
>
> However, now I'm having for the first time in years a problem with this.
> Programs installed _from the packages_ fail to start with this problem:
>
> okular: symbol lookup
> error: /home/alex/local/kde4/lib/kde4/plugins/styles/oxygen.so: undefined
> symbol:
> _ZNK6KStyle26standardIconImplementationEN6QStyle14StandardPixmapEPK12QStyleOptionPK7QWidget
>
>
> All KDE4 apps fail the same. Now I'm completely puzzled by this. I can't
> understand how a program which comes from the Debian package, tries to load,
> open or link against a file that it should not know that even exists. I've
> double checked that LD_LIBRARY_PATH and KDE* variables are not set, and PATH
> is set, but doesn't include stuff from that directory.
>
> Any ideas?

Remove ~/.config/Trolltech.conf. oxygen.so is a Qt plugin and Qt
caches plugin information in that file for quick-loading them. It is
generally safe to remove that file, I do that all the time.


Reply to: