RFC v2: adding a temporary, non-BC gauranteed, 'private' library
Friedrich W. H. Kossebau
kossebau at kde.org
Fri Apr 24 11:20:52 BST 2009
Vrendedi, le 24 avril 2009, à 11:21, Modestas Vainius a écrit:
> Why do you insist on creating shared libraries? If ABI is unstable, create
> static libraries instead (or at least make it an option). Static libraries
> will ensure that:
> 1) use of the library is not widespread. It is experimental after all.
> 2) developers do not have to deal with sonames, abi and other versioning
> nonsense when there is no intention to keep ABI stable (your goal should be
> to develop a stable API/ABI, not to keep library experimental forever). 3)
> it's bad from security support POV, but if 1) is met, it may be more
> acceptable than suffering from constant ABI brekages.
Interesting idea, so it would be solved at compile time, at the cost of some
Just I wonder if there won't be clashes if a program links against the static
lib, but also links against a dynamic lib which itself is linked against the
static lib (which could be of another, incompatible version). Does that work,
or will there be some internal symbols left which then might lead to wrong
> What's more, I recommend to create a new module in trunk/KDE/ for this.
One module might not catch all dependency chains, see my other email. There
could be libs, which kdepimlibs depends on, others which themselves depend on
kdepimlibs, etc. So you can't say when to compile the whole module, before
kdepimlibs or after.
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
More information about the kde-core-devel