Re: [boost] GCC and -isystem

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.
> -static-gcc:
>
> -static-gcc:
>
>     Links in "libgcc.a"/"libgcc_eh.a" instead of "libgcc_s.so"
>
> -static:
>
>     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:

 `-static'
      On systems that support dynamic linking, this prevents linking
      with the shared libraries.  On other systems, this option has no
      effect.
 
 `-shared'
      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)
 
 `-shared-libgcc'
 `-static-libgcc'
      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
      `libgcc'.
 
      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
      `libgcc'.

    ---------- 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.

-- 
Alkis