This is the mail archive of the cygwin-apps mailing list for the Cygwin 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: 64bit: cygstdc++-6.dll


On 25/03/2013 08:52, Corinna Vinschen wrote:
> On Mar 24 03:33, Yaakov (Cygwin/X) wrote:

>> In any case, the error is a result of adding one of Dave Korn's patches:
>>
>> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29
>>
>> I have omitted that patch in the new 4.8.0-1.  Hopefully Dave can
>> explain the purpose and necessity of that patch, since it would seem
>> that using (at least that hunk of) it would require rebuilding most
>> C++ packages in 64bit/release; if it's really necessary, then we
>> will want to do that sooner rather than later.

  I believe the patch is no longer necessary.  I added it originally after a
discussion about the implications of exporting typeinfo from DLLs with Danny
Smith in the GCC bugzilla; he was of opinion that there might be incomplete
typeinfos that could not be fully resolved until final link-time of an
application, so the purpose of this patch was to place typeinfo objects into
the cygstdc++.dll.a rather than in the DLL itself.  The idea being that every
app that linked against the DLL would get a copy of the still-relocatable
typeinfo object files from the import library during its own final link.

  I'm now convinced that Danny was needlessly worried.  The cxx-abi does refer
to this situation, in section 2.9.1:

> <b>NOTE</b>: Note that the full structure described by an RTTI descriptor
> may include incomplete types not required by the Standard to be completed,
> although not in contexts where it would cause ambiguity. Therefore, any
> cross-references within the RTTI to types not known to be complete must be
> weak symbol references.

  But I don't think this applies to any of the built-in types in libstdc, so I
think it's safe to include their typeinfo in the DLL and export it.

> That I don't quite understand either.  If this is only about missing
> exported symbols and not about the name, how are the already built
> C++ packages affected?  They could be built, so they didn't use this
> symbols, apparently.

  Removing the patch should generate a backwardly-compatible DLL.  Existing
applications already linked against the DLLs will have their own copies of the
typeinfo objects pulled in from the import library, so it won't matter that
the newer DLL also exports such a name (note that we compare typeinfos by name
string under Cygwin, rather than by pointer equivalence.)  New applications
linking against the new DLL will simply pull in an import table reference
rather than the entire typeinfo object file.

  The backward incompatibility came from adding the patch after previously
having released a version of the DLL without the patch which therefore had all
the typeinfos exported, as the applications linked against the previous
version of the DLL would still expect the typeinfo imports to be available,
but now the typeinfos would only be available as objects in the import library.

  In short: it was a precautionary measure, it's now superfluous.  I'll remove
it from the next full release of 32-bit GCC as well.

    cheers,
      DaveK


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