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


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


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