From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31652 invoked by alias); 14 Apr 2014 18:54:43 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31615 invoked by uid 48); 14 Apr 2014 18:54:39 -0000 From: "ktietz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin Date: Mon, 14 Apr 2014 18:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: ktietz at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-04/txt/msg01041.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830 --- Comment #12 from Kai Tietz --- (In reply to Denis Excoffier from comment #10) > Created attachment 32595 [details] > gdb session catching signal SIGABRT Some comments here: - it might be helpful to install proper debug-information (cygwin1.dbg doesn't match cygwin1.dll) - to ease debugging it might be helpful to translate gcc without optimizations - As side-note: is there by any chance -std=c++11 active on built? The issue seems to be a global-destructor. The issue might be that a) A library doesn't register .eh_frame. Nevertheless tries to destruct it b) There is tried to destruct it more then once. (Maybe try to set a break-point on that function to find if it get called more then once) c) Issue might be to have mixed static/shared version. This could lead to register/deregister-issues too. In general it would be of interest to learn what destructors (by whom) are present in the list called by do_global_dtors (&__DTOR_LIST__)