[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static vs. shared libraries

From: John Calcote
Subject: Re: static vs. shared libraries
Date: Mon, 09 Jun 2008 11:55:32 -0600
User-agent: Thunderbird (X11/20080226)

Hash: SHA1

Ralf Wildenhues wrote:
> * John Calcote wrote on Mon, Jun 09, 2008 at 07:23:31PM CEST:
>> Ideally, I'd like to build both shared and static ftk libraries, but
>> choose to link ftk statically into flaim using a flaim configure option.
> Why?  (serious question)
> 1) If ftk does not have a stable API yet, it is not suitable as
> independent shared library; you should build a static one only
> (either as lib_LIBRARIES = libftk.a, or, with libtool using
> libftk_la_LDFLAGS = -static)
> 2) If ftk does have a stable API, then why waste space in flaim by not
> using the shared library?
> 3) There may be serious reasons for doing what you want (not many tho).
> In that case, you could consider creating separately a libftk_static.a
> or a (static) convenience archive to which you link
> flaim.  Let me repeat that this is often not the right thing to do.
> Mixing static and shared variants of the same code leads to trouble
> in the long run; example: flaim depends on libfoo which depends on
> libftk (shared); flaim incorporates code from libftk (static).  All
> kind of "interesting" errors ensue ...

Thanks Ralf. This is sort of what I was thinking, but I wanted to
verify. It seems this is another case of the Autotools "encouraging" one
to do the right thing.

BTW, I've had trouble in the past trying to link libtool libraries
against non-libtool convenience libraries. Usually, these problems crop
up as a result of not generating PIC code in the convenience library.

It's libtool's job to determine what flags you need to generate PIC code
on a given platform, so wrapping non-libtool libraries with the
appropriate checks to determine if PIC is supported is tantamount to
duplicating a lot of what libtool already does for you.

Thus, it would be nice if libtool were a bit more liberal in allowing
the above scenarios, because, as you say, there really are good reasons
for doing it (occasionally).

The fact is, however, the more I think about it, the more I realize that
most of these reasons are really just carry-overs from the Win32 world,
where shared libraries of one form or another are more of a pain in the
neck than they are on Linux.

Thanks again!
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]