This is the mail archive of the
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: marco atzeri <marco dot atzeri at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 25 Mar 2013 10:18:06 +0100
- Subject: Re: 64bit: cygstdc++-6.dll
- References: <514C9EB4 dot 4000203 at gmail dot com> <20130323095047 dot GC2387 at calimero dot vinschen dot de> <514EBA42 dot 7010701 at users dot sourceforge dot net> <20130325085219 dot GF2387 at calimero dot vinschen dot de>
On 3/25/2013 9:52 AM, Corinna Vinschen wrote:
On Mar 24 03:33, Yaakov (Cygwin/X) wrote:
On 2013-03-23 04:50, Corinna Vinschen wrote:
On Mar 22 19:11, marco atzeri wrote:
has at least a missing entry point from previous dll
cmake fails with
"_ZTVN10_cxxabiv117_class_type_infoE could not be located"
However, a quick glance into the symbols exported by libstdc++.a
shows that the above symbol exists, but with additional leading
It's hard to see, but the error message actually does have double
I don't quite understand. From what Marco pasted above, it doesn't.
I copied manually from the windows error message, so Yaakov highlighted
that I have missed the double underscores as "hard to see".
The x86_64 ABI does not prepends underscores in front of symbols,
so there has evidently gone something wrong. I checked my the Linux
cross toolchain and it is also using the symbols with additional
leading underscores. Off the top of my head I don't see where this
discrepancy is caused.
The PE underscore only applies to the very beginning of a symbol,
not to every component of a C++ symbol name. Those double
underscores are straight from libstdc++ code, as they are internal
In any case, the error is a result of adding one of Dave Korn's patches:
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.
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
I'm slightly confused now...