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. > > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University
sounds reasonable; Bernhard, would you mind amending your patch in that direction?
