Binary compatiblity for

Hugo Pereira Da Costa hugo at
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, 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 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
>> The apps from there load the 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.
>> Eg:
>> qtcreator: symbol lookup error: 
>> /usr/lib64/kde4/plugins/styles/
>> 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.
>> Andras

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list