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

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

    Hi all,

  The series of patches (contained in the four follow-ups to this post) allow
Windows platforms to compile libstdc++ as a shared DLL, which is desirable on
Windows for all the same reasons as on other platforms.  It is derived from
work by Aaron, Danny and myself that has been previously developed in the
Cygwin and MinGW distro compiler versions.

  They have been separated for ease of review, but logically they need to be
applied as a group.  Danny and Aaron, I've CC'd you guys because it's not
quite complete: I'm not set up for testing on MinGW, and it needs a couple of
#defines and/or maybe a spec modification to work fully on your platform;
details follow inline.  (It will however work almost completely straight off,
and will not break bootstrap, but will only be fully conformant when compiling
with -static to avoid using the DLL until these issues are addressed; whether
or not to make static linking the default for now is one of them.)

  There are a number of differences between a Windows DLL and an ELF DSO,
which account for the bulk of this patch - otherwise patch #3/4 would suffice
entirely by itself.

  First up is that windows DLLs cannot contain any undefined references; they
must be fully resolved at final link time.  This makes life difficult for
operators new, delete, etc. etc., which are supposed to be replaceable
(n2800#17.6.4.6), as any references from within libstdc++ to those functions
has to be resolved when the DLL is linked; this leaves no way to interpose
them if the main application has a replacement version for one.

  In Cygwin we have added support in the form of forwarding wrapper functions,
applied using LD's --wrap option.  MinGW will need to adopt a similar or
equivalent approach, as the DLL is not strictly conformant if it does not
support this facility; for that reason, Aaron and Danny, you might want to
consider adding the newly-available "--static-libstdc++" to the default MinGW
link spec until such time as support to make it work is available (perhaps in
the MinGW static crt*.o?).

  Disallowing unresolved references in DLLs also impacts on typeinfo, as it
means COMDAT selection gets performed twice, once when the DLL is linked and
once when the user's app is linked.  We deal with that by building libstdc++
to not use merged typeinfo or inline comparison of typeids.  It's not as
efficient as it could be, but at least it works correctly.

  The final patch adds DLL import attribute annotations to objects, classes,
functions and templates in libstdc++ that need to be imported from the DLL by
user applications.  This is pretty much essential for a library of the size
and scale of libstdc++ on Windows platforms; without doing so, user
applications would end up relying on LD's (gnu-specific) auto-import feature,
which would result in them becoming bloated with anywhere from dozens to
thousands of single-entry import tables (one per reloc in the excutable
referring to a symbol from the DLL!), with consequent effects on start up
time; dllimport really is necessary for Windows applications to link
efficiently against DLLs.

  As I said at the start, this is derived work and has been tested in anger in
the Cygwin and MinGW distros for some time.  I have also run a full bootstrap
and test cycle for c,c++,fortran,java,objc,obj-c++, including libffi,
libgomp,and libjava (and libstdc++ of course), and there are no regressions.

Before: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg01813.html
After:  http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg01814.html

  The test results suffered a number of transient task spawning failures,
which happens sometimes on Cygwin under heavy strain, and I was running three
testsuites at once; I found a number of stuck processes at various stages
during testing.  Most of these in fact took place with the unpatched compiler
and make it look like my patch fixed a load of bugs that it in fact didn't,
but I went back and manually re-ran all the tests that failed for one compiler
but not the other and made sure they did in fact compile and pass execution,
and they all did.  There is known noise in the libstdc++ pthread_mutex-related
and Java process- and thread- related tests which happens all the time, and a
number of load-related timeouts in the libjava that I haven't yet verified
because I can't figure out how to run libjava testsuite cases manually, so
I'll be re-running the libjava tests on the patched compiler while waiting for
review and input from the MinGW team.  Given that the results were identical
everywhere else, I don't anticipate finding any real failures.

  So, once I'm sure about the libjava tests, and once we know what to do about
a) os_defines.h and b) spec adjustments for MinGW, and subject to the reviews
of the individual patches: OK for HEAD?

    cheers,
      DaveK