patch: c/cxxflags for static libraries

Alexander Neundorf neundorf at kde.org
Mon Jul 17 21:45:33 CEST 2006


On Monday 17 July 2006 20:49, Simon Hausmann wrote:
> On Monday 17. July 2006 19:46, Alexander Neundorf wrote:
> > On Monday 17 July 2006 18:33, Simon Hausmann wrote:
> > > On Monday 17 July 2006 18:02, Alexander Neundorf wrote:
> > > > On Monday 17 July 2006 00:12, Simon Hausmann wrote:
> > > > > On Sunday 16. July 2006 20:31, Thiago Macieira wrote:
> > > > > [...]
> > > > >
> > > > > > If you add a .o that happens to be in an ar archive into a shared
> > > > > > library, you've got a convenience library, not a static library.
> > > > > > In those cases, just link the .o once and for all. There's no
> > > > > > need to create the archive.
> > > > >
> > > > > Yes, but as long as the build system offers this feature people
> > > > > will use it. So I suggest that we either drop the feature
> > > > > alltogether or we use -fPIC there as well. But offering it as
> > > > > feature that only works on i386 when linked into a final shared
> > > > > object is not a good idea IMHO.
> > > >
> > > > Building convenience libs is not supported out-of-the-box by cmake.
> > > > What should we drop ?
> > >
> > > Well, STATIC seems to work out of the box as keyword for
> > > kde4_add_library.
> >
> > Ah, yes.
> > Do you think we should disable static libs for KDE4_ADD_LIBRARY() ?
> > I mean, it's prefectly ok to build a static lib as long as you don't link
> > it into a shared library.
>
> And exactly that, as I tried to point out, happens all the time in KDE,
> since most of the targets in KDE are either shared libraries or kdeinit
> modules, both of which require -fPIC.
>
> Andras' mail on kde-core-devel is just another example of that as he
> hits /exactly/ this problem. 

Yes.

> Either we disable STATIC (and break the build)

Well, it is already broken.
I don't have a strong opinion on this, so for me it would be ok to disable the 
"STATIC" for KDE4_ADD_LIBRARY().
But actually the STATIC works as it should, but it just doesn't behave the 
same way as libtool convenience libs. 

> or we add -fPIC to the build flags (as suggested in my initial patch in
> this thread). My vote is on the latter, but ultimately I don't care as long
> as we solve it :)


From a configure script:

For Solaris:
      solaris2.[0-5] | solaris2.[0-5].*) ;;
      *) # Supported since Solaris 2.6 (maybe 2.5.1?)
	whole_archive_flag_spec='-z allextract$convenience -z defaultextract' ;;

For GNU ld:

      # ancient GNU ld didn't support --whole-archive et. al.
      if $LD --help 2>&1 | grep 'no-whole-archive' > /dev/null; then
 	whole_archive_flag_spec="$wlarc"'--whole-archive$convenience 
'"$wlarc"'--no-whole-archive'

For Mac:

      whole_archive_flag_spec='-all_load $convenience'

So the flags have to be used when linking the static library into the shared 
library, it's different for different platforms, and maybe not supported at 
all for Windows.

So for now I could disable the STATIC keyword and print a warning if it is 
used. 
If we really want this, I could try to do something in our cmake script files 
(checking the platform and trying to insert the correct flags at the correct 
position), which might not work on Windows, or a feature in cmake would be 
needed:
http://www.cmake.org/Bug/bug.php?op=show&bugid=1790&pos=20

For now I'd recommend to just compile all source files into the shared 
library. This works and does so on all platforms.
Which problems does it actually cause ?

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net


More information about the Kde-buildsystem mailing list