Re: [PATCH, 3/4] Enable libstdc++ as a DLL on windows platforms.

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Charles Wilson wrote:
> Dave Korn wrote:

> Since users on windows may already be accustomed to defining (or not
> defining) "_DLL" depending on whether they wish to link against the
> shared (or static) C/C++ runtime(s), we choose to use the same symbol?

> (Of course, end users still aren't REQUIRED to use -D_DLL when linking
> with --shared-libstdc++. Even with your changes in these four patches,
> users could still choose to rely on auto-import if they want their image
> size to explode with "thousands of single-entry import tables" with
> "consequent effects on start up time".).

  Right.  I didn't in fact design this myself, it was in patches I inherited
from Aaron and Danny, so they may want to explain it, but as far as I can see
it's efficiency not correctness, so let's just leave it to the user, and let's
use the standard name they're all already familiar with.

> Third, is it possible to "mix" the C++ and C runtimes when linking a
> single image -- that is, --static-libgcc and --shared-libstdc++, or vice
> versa (this "mixing" is not possible on MSVC, because the same linktime
> flag is used to control both C and C++ runtime).  

  Not all combinations are valid.  You can have static libstdc with shared
libgcc, but static libgcc with shared libstdc won't work.  (At termination
time, the exe gets destroyed before the libraries are unloaded/destroyed; if
libgcc is statically linked it will be destroyed as part of the exe; libstdc++
likes to throw an exception during its termination; after libgcc has been
destroyed you can't throw exceptions because libgcc has deregistered its own
unwind info tables and so the throw routine in libgcc can't unwind the stack
because it can't find the info to unwind past the first frame - it's own - and
get into the rest of the call stack.)

> If it is possible,
> then ... we probably need one of the following:
>   a) distinct compiled time flag for clients of the libraries to define,
> instead of _DLL for both, OR
>   b) policy decision that the C runtime shall not decorate any items
> with declspec(dllimport) at all.  This implies that when linking against
> the shared libgcc then the auto-import functionality will be used (which
> may not be much of an issue if there are no client-visible data items
> exported by that DLL [*]).

  I think it's a desirable goal to move away from reliance on
auto-import/auto-export in general and do it as properly as possible; the auto
functionality is not as efficient and is really there to provide a convenience
fallback for compiling ported unix code on windows without having to annotate
it all up.

    cheers,
      DaveK