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

[Andreas Pakulat]

On 24.04.09 12:20:52, Friedrich W. H. Kossebau wrote:
> 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?

Well, a shared lib can only use the symbols of the static library
internally. It cannot expose the api of that library itself as linking a
static lib into a shared lib only puts the symbols that are used by the
shared lib into it. Also I'm not sure this is actually possible on all
platforms that KDE supports (Thiago should know the details on that). So I
think this wouldn't be a problem as the app only sees the symbols of the
static library it links to itself.
 
Andreas

-- 
So this is it.  We're going to die.