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: "Dave Korn" <dave dot korn dot cygwin at googlemail dot com>
- To: "Danny Smith" <dansmister at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Sun, 21 Dec 2008 21:27:53 +0000
- 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> <9c03c2dd0811292350sb36882bnd369f1be45a4349d@mail.gmail.com>
Danny Smith wrote:
>
> 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
Thanks Danny. It looks like libsupc++ has been refactored a bit since
you looked at this? There's next to nothing in tinfo.o and tinfo2.o:
/gnu/gcc/release/gcc4-4.3.2-2/build/i686-pc-cygwin/libstdc++-v3/libsupc++ $
nm tinfo.o | grep " [TR] " | cut -d' ' -f3 | c++filt
std::type_info::__do_catch(std::type_info const*, void**, unsigned int) const
std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*, void**) const
std::type_info::__is_pointer_p() const
std::type_info::__is_function_p() const
std::type_info::operator==(std::type_info const&) const
std::type_info::~type_info()
std::type_info::~type_info()
std::type_info::~type_info()
typeinfo for std::type_info
typeinfo name for std::type_info
vtable for std::type_info
/gnu/gcc/release/gcc4-4.3.2-2/build/i686-pc-cygwin/libstdc++-v3/libsupc++ $
nm tinfo2.o | grep " [TR] " | cut -d' ' -f3 | c++filt
std::type_info::before(std::type_info const&) const
and there are all these other files with names like
"fundamental_type_info.o" with typeinfo for stuff like int scalars and so on.
I can't exclude just the first two or the DLL won't link, but the group
of tinfo/tinfo2 and *type_info* seems to form a closed dependency group and
if I exclude them all from export and put them into the import library they
don't get pulled into the DLL's link. Tests are still running but it solved
regression in 20_util/shared_ptr/thread/default_weaktoshared.cc so far. I'm
sending a patch separately that adds an ld option to make this kind of
partitioning between DLL and import library easier to perform.
cheers,
DaveK