Okteta moved to kdereview; kdeutils coordinator?

[Alexander Neundorf]

On Tuesday 01 April 2008, Friedrich W. H. Kossebau wrote:
> Hi Alex & Christian,
>
> Am Montag, 31. März 2008, um 23:22 Uhr, schrieb Alexander Neundorf:
> > On Monday 31 March 2008, Christian Ehrlicher wrote:
> > > Friedrich W. H. Kossebau schrieb:
> > > > If Okteta can move to kdeutils/okteta, the old versions of the
> > > > libraries and parts in kdeutils/khexedit/* will be svn rm'ed, as they
> > > > are turned obsolete by the Okteta code from kdereview.
> > > >
> > > > Some other (background) information can be found at my blog
> > > > 	http://frinring.wordpress.com/category/okteta/
> > > > and on the kde-apps page
> > > > 	http://www.kde-apps.org/content/show.php?content=77819
> > >
> > > Okteta now also compiles fine on windows.
>
> Thanks. Well, at least in the name of potential Windows users... ;)
>
> > > I saw that you build some convenience static libs - is this intented?
>
> Intended as far as I like to split all things that seem orthogonal to each
> other into separate moduls (as can be seen by the endless number of files
> and directories in Okteta, things like "libframesprint" or "piecetable").
> And I follow the splits also in the CMakeLists.txt. So the moduls can be
> easily moved around, shared, and the single CMakeLists.txt files stay small
> size.
>
> > > Afaik convenience libs should be avoided when possible.
> >
> > Are these static libraries linked into shared libraries ? This really
> > should be avoided (or did we add some linker flag so it works everywhere
> > ?). Using static libraries for _executables_ is ok.
>
> So far there have been only static libraries for executables, so things
> seem fine (or ok, at least :).
>
> Thanks for the reminder. Well, now I am curious: What is the reason
> for "static libraries linked into shared libraries" = nono? And could we
> document this on techbase?

Let's see if I get it right:
Static libs are just a bunch of object files. If you link an executable with a 
static library, all the symbols used in the executable will be resolved. This 
means if it calls foo(), the linker will search in all the object files 
included in the static library for the object file which defines that symbol 
and add that object file to the resulting executable. If foo() is not called 
then the object file is not included in the executable. This is good, it 
saves space etc. and puts only stuff actually required in the resulting ELF 
file.
Now if you do the same with a shared library which you link with a static 
library (...now it gets a bit think on my side), no function at all is every 
referenced (since there is no main, so nothing is every called and no object 
file from the static library is copied into the shared library.
In case this explanation is wrong (nothing at all included because nothing is 
called), then my second guess is this one: 
only the object files of symbols which are referenced somewhere in the object 
files of the shared library are copied into the resulting shared library. 
This would work somewhat and only the object files from the static library 
which are not referenced from the shared library (i.e. which provide 
independent functions/classes) would be lost.

There are flags for many systems which cause the static library to be 
completely included in the shared library, but (AFAIK) this doesn't exist for 
all platforms/toolchains.

I think that should be a rough overview over the issue.

Alex