A little review of kdecore & kdeui
hausmann at kde.org
Sat Apr 8 09:40:49 BST 2006
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?
More information about the kde-core-devel