This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LONG] RF{C,D,A,H}: pe-x86 DLLs (shared libstdc++ and others) vs C++ RTTI vs LD


Dave Korn wrote:
> 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:

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

  Nope, you were right in the first place: doing that fixed one case but
caused a couple of regressions in other (related) tests.  It looks like
linking tinfo/tinfo2 into the DLL but not exporting them, and placing them
into the import library does the right thing.

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]