------- Comment #2 from davek at gcc dot gnu dot org 2010-01-21 03:57 ------- Here's what's going on:
- To implement operator new/delete replacement, we use ld and --wrap to redirect all references to the operator functions into redirection stubs in the cygwin dll. - Each DLL or executable records a list of which (if any) of those operators it provides replacements for. It does this with an array of function pointers in a part of the CRT pre-main() startup. In the array are weak references to all the replaceable operators; any for which overrides are visible at final-link time will get filled out with the addresses of those overrides, and the weakness of the references means they won't cause any functions that aren't already present in the final link to be pulled in from libraries. The references assign asm names to the symbols that use the "__real__" prefix in order that they don't see the Cygwin DLL wrapper functions, just the real actual implementations present. - As an optimisation, we don't apply the wrapper redirection when linking statically. That's because there's no need; any function replacement overrides present in the final link will just automatically override the libstdc++ versions by preventing them from ever being pulled out of the static libstdc++ archive at final-link time. That's all fine as it stands, but:- - Some recent optimisation of EH generation had the effect that, where previously every C++ object was always emitted with a reference to the gxx eh personality function, this reference is now only emitted when strictly needed. - This means that for the first time it became possible that the only references to libstdc++ in a C++ executable undergoing final link might be references to the operator new/delete function(s). - Since these are all redirected to the wrappers in the Cygwin DLL, that can mean there are no unresolved references to pull in anything at all from the libstdc++ import library, and so the resulting executable does not depend on nor cause the libstdc++ dll to be loaded into memory, meaning that the real versions of the replacement functions that the redirect stubs need to redirect to aren't present! - So, the way to prevent that is by also emitting an extern reference to the real version of the operator function in question, which causes the DLL to be imported (even though the imports aren't used directly but only via the redirection stubs in the DLL; the important point being that you have to load libstdc++ so that it can register the default versions of all the operators using its own array of weak (but fully-filled-out) function pointers. This is done in gcc/config/i386/winnt.c, in i386_pe_file_end(). - And that's where it goes wrong. The compiler doesn't know at the time it's emitting assembly whether the final object will be statically linked or not, so it really has no choice but to emit the reference; but if it does end up being statically linked, the wrappers aren't in effect, so there is no "__real__*" function. - That wouldn't be a problem: the toolchain doesn't care about the undefined symbol, because no relocs reference it, and the runtime loader doesn't give a stuff about symbols at all, caring only about the import and export tables. - Except for one final gotcha. Because the undefined references that are emitted to cause the DLL to be loaded are strong undefs - they have to be, since they have to cause an import stub to be pulled in from a library archive. So even though there are no relocs in the object that contains the strong undef, it has the knock-on effect that the weak references in the array of function pointers become strong. And that's where the link failure arises. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
