Binary compatiblity for liboxygenstyle.so
Hugo Pereira Da Costa
hugo at oxygen-icons.org
Fri Feb 24 10:25:13 GMT 2012
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
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].
>> is there any BC guarantee for liboxygenstyle.so.4? If not, i think
>> should be... It is not the first time that you cannot run application
>> 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
>> dynamically, so if that changes in a BIC way, the apps crash and
>> don't start.
>> qtcreator: symbol lookup error:
>> undefined symbol: _ZN6Oxygen7TileSetC1ERK7QPixmapiiii
>> Right now the problem was most probably was the following commit:
>> I know this does not affect regular releases in distributions, but it
>> is very
>> bad for those working/testing KDE master.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel