This is the mail archive of the
mailing list for the Cygwin project.
Re: Updated: gcc-5.2.0-1 (Test x86/x86_64)
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Tue, 6 Oct 2015 23:20:18 +0100
- Subject: Re: Updated: gcc-5.2.0-1 (Test x86/x86_64)
- Authentication-results: sourceware.org; auth=none
- References: <560BC46D dot 3060500 at gmail dot com> <560C0863 dot 70505 at tiscali dot co dot uk> <560C6369 dot 7060602 at gmail dot com> <560C71FB dot 4030005 at tiscali dot co dot uk> <560D2F6D dot 90608 at gmail dot com> <5613F632 dot 1080205 at t-online dot de>
On 06/10/15 17:26, Christian Franke wrote:
cyg Simple wrote:
On 9/30/2015 7:36 PM, David Stacey wrote:
On 30/09/15 23:34, JonY wrote:
On 10/1/2015 00:05, David Stacey wrote:
As far as I know, every gcc release will break C++ ABI, so it would
On 30/09/15 12:15, JonY wrote:
gcc-5.2.0-1 has been uploaded for 32bit and 64bit Cygwin.
This is the first series of the 5.x releases, and should be
as experimental as such.
Have you managed to work around the ABI change in gcc-5 , or will
this require a mass rebuild at the point gcc-5 becomes 'current'?
rebuilding everything C++.
According to the Red Hat blog above, the last time g++ caused an ABI
change was back in the 3.x days, so it hasn't happened for a while. Ah
well, we have maintainers for most packages in Cygwin, so we'll have to
co-ordinate a rebuild.
Regardless, JonY is correct. Every C++ release, regardless of the
vendor, causes an ABI break with shared libraries and the naming of the
object elements (mangled names).
Probably not in this 4.X -> 5.X case. Otherwise the new
cygstdc++-6.dll should IMO be renamed to -6.1, -7 or similar.
Bumping the DLL number wouldn't necessarily fix the problem. You'd still
run into conflicts if one executable loaded two DLLs, each linked
against different versions of libstdc++.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple