RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Friedrich W. H. Kossebau]

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 
larger binaries.

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 
function calls?

> 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.

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta