This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with static linking


On Thu, Jul 16, 2009 at 12:57 PM, Ian Lance Taylor <iant@google.com> wrote:
>
> Jakub Jelinek <jakub@redhat.com> writes:
>
> >> -static option? ?and 3) Is there a way to fix them? ?I've even gone so
> >> far as to manually run collect2 specifying my own hand edited command
> >> line, but nothing I've tried there has worked either.
> >
> > Don't link statically, there are many reasons not to and only very few
> > reasons for it (primarily exception is some system recovery tools that are
> > supposed to work even when shared libraries are hosed).
> > See http://people.redhat.com/drepper/no_static_linking.html
>
> The main reason to link statically is the inverse of Ulrich's first
> reason to link dynamically: if you link dynamically, your program is
> vulnerable to changes in the shared libraries. ?If your program is
> carefully tuned and tested, then changes to shared libraries can
> introduce unexpected performance changes, or even, in the worst case,
> unexpected bugs. ?Another way to say "by fixing a dynamic library you
> can fix a bug in every program in one place" is "by distributing a new
> dynamic library, you can break every program at once."
>
> I think the argument against static linking does not consider the world
> where one builds a carefully tuned executable and then runs it for many
> years. ?In that environment, each change to a dynamic library requires
> careful retesting of all the affected programs. ?But it does not follow
> that we never want to change the library, because not all programs are
> performance sensitive, and new programs require new features.
>
> Ian

There's also much less to deal with from a Q/A and tech support
perspective if you use static linking with a closed source
application, since you can produce 1 binary which works across
multiple distributions and kernels without the user compiling it,
which is what I'm dealing with.  Not necessarily enough to mandate
linking everything statically, I actually have been advocating for a
while to link everything dynamically.  But it is how it is for now,
and I suspect it will take more nagging and more time for there to be
a real switch


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]