From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4217 invoked by alias); 22 Dec 2009 21:04:39 -0000 Received: (qmail 4177 invoked by uid 48); 22 Dec 2009 21:04:27 -0000 Date: Tue, 22 Dec 2009 21:04:00 -0000 Message-ID: <20091222210427.4176.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rwild at gcc dot gnu dot org" 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 X-SW-Source: 2009-12/txt/msg02175.txt.bz2 ------- Comment #20 from rwild at gcc dot gnu dot org 2009-12-22 21:04 ------- Created an attachment (id=19374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19374&action=view) patch to turn off multiple inclusion guard for fenv.h C++ wrapper Comment #18 confirms #13. It is probably sufficient to turn off the inclusion guard for the include_next. However, it is also a slightly risky thing to do; and I'm not quite sure whether it is conceptually the right thing to do. (FWIW, gnulib uses split inclusion guards for include_next in a number of places.) (One risk is backward compatibility requirements stemming from including the header from the installed, possibly older, compiler.) Another strategy that comes to mind is to use -nostdinc++ and then add the other include headers manually, but that is likely even more risky. I'd be interested to see how the clfs build fares with this patch. If it succeeds, bonus points for also installing the just-built compiler and then trying to do another cross build using the just-installed compiler. Building and testing of a native compiler succeeded on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974