-nostdinc++ gcc option is required?

[Farid Zaripov <Fa...@epam.com>]

  Why -nostdinc++ compiler option is used when building the stdcxx on
gcc?

  I know that this option prevents including the gcc C++ headers, but
the C++
headers are included on MSVC and nothing bad was happen on this.

  As for gcc, the all configuration tests which are uses typeid operator
are failed to compile with error: must #include <typeinfo> before using
typeid

Farid.

Re: -nostdinc++ gcc option is required?

[Martin Sebor <se...@roguewave.com>]

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

RE: -nostdinc++ gcc option is required?

[Farid Zaripov <Fa...@epam.com>]

> -----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.

Farid.

Re: -nostdinc++ gcc option is required?

[Martin Sebor <se...@roguewave.com>]

Farid Zaripov wrote:
>   Why -nostdinc++ compiler option is used when building the stdcxx on
> gcc?

To prevent the native C++ headers from being accidentally included.

> 
>   I know that this option prevents including the gcc C++ headers, but
> the C++
> headers are included on MSVC and nothing bad was happen on this.

I'm not sure there is a way to remove the "native" C++ headers from
the MSVC preprocessor search path. We did have serious problems on
this platform dues to some of the native headers (the C++ C libc
kind, maybe?) #including the Dinkumware <yvals.h> which contains
at least one macro (was it _STD?) with the same name as ours. In
general, mixing headers from two different implementations of the
same library often leads to problems that can be extremely hard
to diagnose (ODR violations), so we go the extra mile to prevent
this from happening. On some platforms, it may not be necessary
at the moment, but there's always the possibility that it will
become necessary in the future, however remote it may seem now.

> 
>   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 :) Please open an issue for this problem
and copy the test case into it.

Martin