From: Alkis Evlogimenos (alkis_at_[hidden])
Date: 2002-11-06 01:30:04
On Tuesday 05 November 2002 07:18 pm, Rene Rivera wrote:
> I don't see how that previous discussion lead you to believe that
> runtime-link-static should map to -static-gcc. Could you explain your
> thoughts on that?
I got the impression (maybe mistakenly) that David agreed that
runtime-link-static should map to -static-gcc.
Anyway, from what I understood runtime-link-static and runtime-link-dynamic
specify the way the runtime is linked to a target. Passing -static to gcc
prevents shared linking, period. I personally find this very confusing.
> And for clarity here is what I understand GCC does with -static vs.
> Links in "libgcc.a"/"libgcc_eh.a" instead of "libgcc_s.so"
> Does the above, and in addition changes the behaviour of "-l<library>"
> to lokk for "lib<library>.a" instead of "lib<library>.so". The libraries
> that this includes are at least: libstdc++.so/a, libc.so/a, but probably
> includes others.
gcc's info page uses slightly different wording:
On systems that support dynamic linking, this prevents linking
with the shared libraries. On other systems, this option has no
Produce a shared object which can then be linked with other
objects to form an executable. Not all systems support this
option. For predictable results, you must also specify the same
set of options that were used to generate code (`-fpic', `-fPIC',
or model suboptions) when you specify this option.(1)
On systems that provide `libgcc' as a shared library, these options
force the use of either the shared or static version respectively.
If no shared version of `libgcc' was built when the compiler was
configured, these options have no effect.
There are several situations in which an application should use the
shared `libgcc' instead of the static version. The most common of
these is when the application wishes to throw and catch exceptions
across different shared libraries. In that case, each of the
libraries as well as the application itself should use the shared
Therefore, the G++ and GCJ drivers automatically add
`-shared-libgcc' whenever you build a shared library or a main
executable, because C++ and Java programs typically use
exceptions, so this is the right thing to do.
If, instead, you use the GCC driver to create shared libraries,
you may find that they will not always be linked with the shared
`libgcc'. If GCC finds, at its configuration time, that you have
a GNU linker that does not support option `--eh-frame-hdr', it
will link the shared version of `libgcc' into shared libraries by
default. Otherwise, it will take advantage of the linker and
optimize away the linking with the shared version of `libgcc',
linking with the static version of libgcc by default. This allows
exceptions to propagate through such shared libraries, without
incurring relocation costs at library load time.
However, if a library or main executable is supposed to throw or
catch exceptions, you must link it using the G++ or GCJ driver, as
appropriate for the languages used in the program, or using the
option `-shared-libgcc', such that it is linked with the shared
---------- Footnotes ----------
(1) On some systems, `gcc -shared' needs to build supplementary stub
code for constructors to work. On multi-libbed systems, `gcc -shared'
must select the correct support libraries to link against. Failing to
supply the correct flags may lead to subtle defects. Supplying them in
cases where they are not necessary is innocuous.
>From the above neither -static nor -static-gcc seem to do exactly what is
intended by runtime-link-static but IMHO -static-gcc is closer to that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk