A little review of kdecore & kdeui

[Simon Hausmann]

On Saturday 08 April 2006 10:09, Alexander Neundorf wrote:
> On Saturday 08 April 2006 10:00, Simon Hausmann wrote:
> > On Saturday 08 April 2006 09:40, Alexander Neundorf wrote:
> > > On Saturday 08 April 2006 09:36, Simon Hausmann wrote:
> > > > On Thursday 06 April 2006 01:21, Thiago Macieira wrote:
> > > > > >But I thought it wasn't possible to link a static lib into a
> > > > > > shared lib?
> > > > >
> > > > > It isn't.
> > > >
> > > > What is the problem with that? Why can't we support that if we always
> > > > compile static libraries PIC? (just as we did in KDE3 with libtool)
> > > >
> > > > Or is it the problem of --whole-archive?
> > >
> > > It is unportable and not longer required with cmake.
> >
> > We could indeed as David suggested install sources for classes that we
> > don't want in shared libraries yet, classes for which we don't want to
> > promise binary compatibility yet. But that is certainly not as convenient
> > in usage in applications as linking against a library.
> >
> > What exactly is the problem with compilling them into a static library?
> > What exactly do you think is unportable?
>
> Although I'm currently something like the buildsystem guy, I don't feel
> like one ;-)
> Well, everwhere where it's used there are big comments that it's unportable
> to link static libs into shared libs.

Where can I find those big comments?

Think about it, a static library is just a dummy archive of .o files with an 
optional symbol index. Whether you compile a .cpp file into a .o file with 
flags needed to generate code suitable for shared libraries and then link 
the .o file directly into a shared object or whether you compile it with the 
same flags but put it into an intermediate archive just to extract it later 
on and put it into a shared object doesn't make any difference to the 
generated code. The only important thing is that you use the right flags for 
compilation. (and even that is usually only important for platforms that use 
position independent code for shared libraries, not for windows for example)

> Usually only the symbols which are used are pulled in the shared lib, but
> for some/most/all (?) linkers exist some special flags which cause it to
> pull in the complete static lib.

That is a problem not specific to linking static libraries into shared 
libraries, it is a general 'problem'. I don't think it's a real problem in 
normal usage though unless people use for example use a global object that is 
not reference from anywhere and they rely on their construction. However we 
don't promote the use of global constructors anyway because of various other 
problems. (ctors not being called sometimes, undefined order, etc.)

Here's another simple example: The demos in Qt 4 share a bit of code, which is 
located in $QTDIR/demos/shared. That code is compiled into a static library. 
The demo applications themselves link in that static library and that works 
fine. However there is also $QTDIR/demos/arthurplugin which provides all the 
arthur demos as a plugin for designer, and that obviously also drags in the 
static library. So here a static library is linked into a shared library and 
it is supported on all platforms that Qt supports. Why can't we support the 
same in KDE?

Simon