[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] kcmoduleinfo [WAS] Plugin linking problem
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-08-10 9:04:54
Message-ID: 20070810090454.GA6030 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 10.08.07 10:41:16, Matthias Kretz wrote:
> Regarding your original problem, I think what you need is this:
> 
> libfoo
> plugin_foo linking to libfoo
> kcm_foo linking to libfoo
> 
> libfoo contains the static public methods and properties. If both the plugin 
> and the kcm are loaded they're linking to the same library and share the 
> global data as long as the symbols are really in the lib and not only defined 
> in the header.

Well, this means introducing a shared library just for the purpose of
connecting plugin and kcm, somehow I fail to see why that would be a
better solution. 

The problem with the shared lib is: Either it has to follow bic-rules,
i.e. it has to get a soversion and proper updating of that when it
changes it interface, or it has to get a proper name so that it doesn't
need a soversion but also can't clash with the same lib in kde3 or
kde5.

KDevelop currently does the latter, but those shared libs do a lot more
than just providing some config-read/write stuff. I really don't see
enough benefit from such a library for just reading/writing config stuff
to justify removing the possibility of multiple entry points. To me it
just sounds like a bad workaround.

Andreas

-- 
You will be awarded a medal for disregarding safety in saving someone.
[prev in list] [next in list] [prev in thread] [next in thread]