Return-Path: 
 <stdcxx-dev-return-5552-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 34080 invoked from network); 16 Oct 2007 14:16:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 16 Oct 2007 14:16:37 -0000
Received: (qmail 91534 invoked by uid 500); 16 Oct 2007 14:16:24 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 91522 invoked by uid 500); 16 Oct 2007 14:16:24 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 91511 invoked by uid 99); 16 Oct 2007 14:16:24 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Oct 2007 07:16:24 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Oct 2007 14:16:28 +0000
Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59])
	by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l9GEDOwP010806
	for <stdcxx-dev@incubator.apache.org>; Tue, 16 Oct 2007 14:13:24 GMT
Received: from [10.70.3.143] ([10.70.3.143]) by qxvcexch01.ad.quovadx.com with
 Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 16 Oct 2007 08:12:28 -0600
Message-ID: <4714C71D.1000708@roguewave.com>
Date: Tue, 16 Oct 2007 08:13:49 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: -nostdinc++ gcc option is required?
References: <7BDB2168BEAEF14C98F1901FD2DE6438010B2FA3@epmsa009.minsk.epam.com>
 <471298B9.4030801@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE64380117E47E@epmsa009.minsk.epam.com>
In-Reply-To: 
 <7BDB2168BEAEF14C98F1901FD2DE64380117E47E@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Oct 2007 14:12:28.0489 (UTC)
 FILETIME=[95880B90:01C80FFE]
X-Virus-Checked: Checked by ClamAV on apache.org

Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Monday, October 15, 2007 1:31 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: -nostdinc++ gcc option is required?
>>
>>>   As for gcc, the all configuration tests which are uses typeid 
>>> operator are failed to compile with error: must #include <typeinfo> 
>>> before using typeid
>> Right. We need to deal with this, certainly if it's affecting 
>> the correctness or functionality of our library (in which 
>> case, we need a test case :) 
> 
>   I've tried to make config with and without -nostdinc++ option
> using gcc 4.2.0/Cygwin and no difference was detected in config.h.

We need to think about this carefully. It's important that we use
the same options when configuring the library as when building or
using it. If we need access to the native headers only at a single
stage of the build process it doesn't make sense to risk exposing
them during other stages. I see no reason not to drop -nostdinc++
when compiling the config test(s) where it causes trouble but I'm
not comfortable dropping it altogether.

If you'd like to do this, since we have no general interface for
removing command line options for specific config tests, the one
I've been contemplating extends the "LDOPTS = <linker-options>"
syntax understood by GNUmakefile.cfg to also accept LDFLAGS and
the -= (and possibly also +=) operator to remove the named set
of options. I.e., in the TYPEINFO.cpp test, we would add
a comment like so:

     // CPPFLAGS -= -nostdinc++

which the config infrastructure would interpret to as a request
to remove the option from CPPFLAGS. The only issue to resolve
is how to deal with conditionals (if the option is to be removed
only under specific circumstances). I don't have any idea how to
do that at this time.

Martin