The Nepomuk Situation

David Faure faure at
Mon May 7 10:42:33 BST 2012

On Monday 07 May 2012 13:06:15 Vishesh Handa wrote:
> On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela <nospam at> wrote:
> > On 2012-05-07, Vishesh Handa <me at> wrote:
> > > Right.
> > > 
> > > We could maintain BC and SC by not touching the kdelibs nepomuk, and
> > > just
> > > making nepomuk-core a dependency of kdelibs. But that would result in
> > 
> > both
> > 
> > > nepomuk-core and kdelibs installing the same headers.
> > 
> > what happens if both libraries are loaded into the same process?
> I'm not sure. I'm assuming that it would result in some sort of linker
> errors.

Not if libnepomukcore is brought in by the application, and libnepomuk is 
brought in by a dlopened plugin. In such a case, you get no clear error, you 
get random crashes.

The solution is usually to namespace the symbols (classes, standalone 
functions etc.) so that they don't conflict.
Of course that makes the porting effort a bit higher, but it's the only way to 
have both things side by side during the transition period.

See knewstuff2 (namespace KNS) vs knewstuff3 (namespace KNS3) for instance ;)

David Faure, faure at,
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

More information about the kde-core-devel mailing list