On 5 April 2013 11:23, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: > On Fri, Apr 5, 2013 at 4:13 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> > wrote: >> Gabriel Dos Reis <g...@integrable-solutions.net> writes: >> >>> On Fri, Apr 5, 2013 at 4:01 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> >>> wrote: >>>> Gabriel Dos Reis <g...@integrable-solutions.net> writes: >>>> >>>>>> diff --git a/libstdc++-v3/include/c_global/cstdio >>>>>> b/libstdc++-v3/include/c_global/cstdio >>>>>> index fcbec0c..037a668 100644 >>>>>> --- a/libstdc++-v3/include/c_global/cstdio >>>>>> +++ b/libstdc++-v3/include/c_global/cstdio >>>>>> @@ -131,7 +131,9 @@ namespace std >>>>>> using ::sprintf; >>>>>> using ::sscanf; >>>>>> using ::tmpfile; >>>>>> +#if !defined __UCLIBC__ || defined __UCLIBC_SUSV4_LEGACY__ >>>>>> using ::tmpnam; >>>>>> +#endif >>>>>> using ::ungetc; >>>>>> using ::vfprintf; >>>>>> using ::vprintf; >>>>>> -- >>>>>> 1.7.10.4 >> b>>>> >>>>> >>>>> Sounds good to me. >>>> >>>> Do we really want to use target-specific macros directly instead of >>>> defining something more abstract either via a configure test or a define >>>> in config/os/uclibc? >>>> >>>> Rainer >>> >>> What would your suggestion for defineingsomething more abstract that >>> reliably >>> says whether the feature is deprecated or absent? >> >> It seems _GLIBCXX_USE_TMPNAM would be in line with the other macros I >> see. Than either configure could test if tmpnam() is available without >> special additional macros or config/os/uclibc/os_config.h could define >> it to 0, with a default of 1 (best decided by the libstdc++ >> maintainers). >> >> The configure route seems cleaner to me, especially given that >> Bernhard's rationale for uClibc no longer providing it by default >> suggests that other systems might follow in the foreseeable future.
> sounds reasonable; Bernhard, would you mind amending your patch in > that direction? I'll have a look. Thanks,
