This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Question on enabling c++ to_string to arm-none-eabi target
- From: Terry Guo <flameroc at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, joey dot ye at arm dot com
- Date: Thu, 31 Oct 2013 20:55:56 +0800
- Subject: Re: Question on enabling c++ to_string to arm-none-eabi target
- Authentication-results: sourceware.org; auth=none
- References: <CAGbRaL4nMX9XyvFJu_s4sSPB5_qYv_zvUCeXGut7PB5On2m06Q at mail dot gmail dot com> <CAH6eHdQX+cfv9+G7HYWK6MjHqZjM5tuXVOVGMmk9g4e7XRFCYg at mail dot gmail dot com>
On Thu, Oct 31, 2013 at 7:50 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 31 October 2013 10:10, Terry Guo wrote:
>>
>> The stdio.h from Newlib defines vscanf function as:
>>
>> #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)
>> int _EXFUN(vscanf, (const char *, __VALIST)
>> _ATTRIBUTE ((__format__ (__scanf__, 1, 0))));
>> #endif
>>
>> And the libstdc++-v3 configuration always uses option -std=c++98 to
>> compile above code, this option indicate the define of
>> __STRICT_ANSI__. So always fail to compile above code with error
>> message:
>>
>> conftest.cpp:36:19: error: 'vscanf' was not declared in this scope
>> vscanf("%i", args);
>
>
> We have to use -std=c++xx not -std=gnu++xx (and so define
> __STRICT_ANSI__) because users might want to use that, and we have to
> know if the functions are available in all cases.
>
>
>> Finally failing to compile the conftest.cpp causes the disable of c++
>> to_string function. So what should I do to let those conftest.cpp
>> pass? By changing option from -std=c++98 to -std=gnu++98 or removing
>> the IF macros from stdio.h? Please help. Thanks in advance.
>
>
> Using -std=gnu++98 would not be correct, because the functions would
> still not be defined if users compile with -std=c++11 (which also
> defines __STRICT_ANSI__), so GCC would build OK but users would get
> errors when they compile.
>
> It has been suggested in the past that we might want to split up the
> _GLIBCXX_USE_C99 test to be more fine-grained. For example, C99
> features needed by C++11-only features (such as std::to_string) could
> test using -std=c++11, which sets __cplusplus to 201103L, and a
> conforming C library should enable the full C99 library in that case
> (it looks like newlib wouldn't though, that's a bug in newlib.)
>
> Alternatively, we could predefine __STDC_VERSION__ to 199901L to
> coerce newlib into providing the C99 library (it's
> implementation-defined whether that is defined by C++ implementations
> or not.)
Thanks for your valuable help. I know the reason now.
BR,
Terry