On 02/24/2012 11:21 AM, Hugo Pereira Da Costa wrote:
Hi Andras,
no there is no guarantee for liboxygenstyle.so.4, and I don't plan to
guarantee it.
It is all internal to kde-workspace, and has no public api.
the fact that oxygen gets broken for kde installed from source due to
incorrect plugin path is an issue with Qt installantion, and/or with
local KDE install (experts should confirm), that must be fixed
upstream, disregarding of the above. In fact the same issue can lead
(and has led) to crashes elsewhere, notably in the decorations.
Therefore I don't think it justifies ensuring the the BIC you ask,
which would generate extra -and IMHO unnecessary- complexity, if not
overhead.
If I remember correctly, the recipy for getting the right pluggin path
(and thus avoid the crashes -always-), is to edit
$HOME/.config/Trolltech.conf, and remove (or fix) the "libraryPath"
section in [qt].
Sorry,
Hugo
Hi,
is there any BC guarantee for liboxygenstyle.so.4? If not, i think
there
should be... It is not the first time that you cannot run application
installed
by your distribution under a self-compiled KDE master, because BIC
issues in
lliboxygenstyle.so. The apps from there load the oxygen.so plugin
from the
system directories, but as the link against the master's
liboxygenstyle.so
dynamically, so if that changes in a BIC way, the apps crash and
don't start.
Eg:
qtcreator: symbol lookup error:
/usr/lib64/kde4/plugins/styles/oxygen.so:
undefined symbol: _ZN6Oxygen7TileSetC1ERK7QPixmapiiii
Right now the problem was most probably was the following commit:
http://commits.kde.org/kde-workspace/04490c8a827347ed41b9b1bee0539cea750ddf50
I know this does not affect regular releases in distributions, but it
is very
bad for those working/testing KDE master.
Andras
