This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [LONG] RF{C,D,A,H}: pe-x86 DLLs (shared libstdc++ and others) vs C++ RTTI vs LD
- From: "Danny Smith" <dansmister at gmail dot com>
- To: "Dave Korn" <dave dot korn dot cygwin at googlemail dot com>
- Cc: binutils at sourceware dot org
- Date: Sun, 30 Nov 2008 20:50:06 +1300
- Subject: Re: [LONG] RF{C,D,A,H}: pe-x86 DLLs (shared libstdc++ and others) vs C++ RTTI vs LD
- References: <2ca21dcc0811291717o382dc09dy67beefca36b28f5f@mail.gmail.com>
On Sun, Nov 30, 2008 at 2:17 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> The problem:
> -============-
>
> A naive attempt to build shared libstdc++ as a DLL (by trivially adding the
> '-no-undefined' switch to the libtool link flags) shows massive regressions
> in the testsuite, which on inspection turn out to be very largely caused by
> "excess errors": the linker is emitting an awful lot of warnings such as:
>
> "Info: resolving typeinfo for std::runtime_error by linking to
> __imp___ZTISt13runtime_error (auto-import)
> /usr/i686-pc-cygwin/bin/ld: warning: auto-importing has been activated
> without --enable-auto-import specified on the command line.
> This should work unless it involves constant data structures referencing
> symbols from auto-imported DLLs."
>
> There is also a major regression in the number of execution tests failing,
> as compared to the default static libstdc++ build.
>
> [ Note that in both cases (shared or static libstdc++), I have been testing
> after applying a patch from Danny that adds '_GLIBCXX_IMPORT' declarations
> through libstdc++ in order to add __attribute__((dllimport)) to the basic
> class declarations, i.e. in libstdc++-v3/config/os/newlib/os_defines.h, add
>
> #ifdef _DLL
> #define _GLIBCXX_IMPORT __attribute__((dllimport))
> #else
> #define _GLIBCXX_IMPORT
> #endif
>
> and then mark all the basic classes in libstdc++ like so:
>
> - extern template class basic_ios<char>;
> + extern template class _GLIBCXX_IMPORT basic_ios<char>;
>
> or
>
> - class strstreambuf : public basic_streambuf<char, char_traits<char> >
> + class _GLIBCXX_IMPORT strstreambuf : public basic_streambuf<char,
> char_traits<char> >
>
> or
>
> - class failure : public exception
> + class _GLIBCXX_IMPORT failure : public exception
>
> etc. ]
>
If I remember correctly, there were no problems with *user-defined*
types and TI tables (with above _GLIBCXX_IMPORT additions). The
problems arose from *language-defined* types with TI tables generated
in libsupc++'s tinfo.cc and tinfo2.cc. Excluding those 2 objects
from libstdc++.dll and adding them as statically-linked objects to the
libstdc++.a import lib allowed the comdat linkage (linkonce)
mechanism to work.
Danny