This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 25 Mar 2013 09:52:19 +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>
- Reply-to: cygwin-apps at cygwin dot com
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:
> >>latest libstdc++6-4.8-20130319-1
> >>
> >>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
> >underscores:
> >
> > _ZTVN10__cxxabiv117__class_type_infoE
> > ^ ^
>
> It's hard to see, but the error message actually does have double
> underscores.
I don't quite understand. From what Marco pasted above, it doesn't.
> >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
> symbols.
>
> 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.
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.
I'm slightly confused now...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat