[Python-bugs-list] Python 1.6a1 - installation report (PR#263)

[guido@python.org]

> > Seems a bug in Linux -- apparently strptime() is not declared anywhere.
> > Or if it is, it is in a header file of its own.  Do you know which header
> > file, and how I can know if it's a good idea to #include it?
> 
> Grepping `/usr/include' found it in `/usr/include/time.h'.  Here are the
> associated lines (I'm including it whole as a MIME attachment).
> 
> # ifdef __USE_XOPEN
> /* Parse S according to FORMAT and store binary time information in TP.
>    The return value is a pointer to the first unparsed character in S.  *=
> /
> extern char *strptime __P ((__const char *__s, __const char *__fmt,
> 			    struct tm *__tp));
> # endif
> 
> 
> It seems that `__USE_XOPEN' is defined from within `/usr/include/features=
> .h'
> (also included whole below, as another attachment).  Many system files
> include `features.h'.  For it to be defined, `_XOPEN_SOURCE' has to be se=
> t
> at compilation time.  This one, in turn, gets defined if `_GNU_SOURCE'
> is defined at compilation time, which I guarantee through `config.h'
> in the packages I distribute myself.  This might be worth doing for Linux.

I have to admit I am very naive about all the symbols that various
vendors (and GNU) require you to define in order to enable various
variants of their libraries and/or header files.  I was hoping that
autoconf would do this -- but apparently it doesn't or I must still
tell it to.  I also don't know what the typical downside might be of
turning on such symbols.

Can you suggest a patch to configure.in that does the right thing?  I
simply don't have the background knowledge to decide what to do here,
and the danger exists that if there's a complaint only from a small
corner of the universe that it is their responsibility to send me a
patch that doesn't break other corners of the universe -- I can't
possibly know what's right for all.

--Guido van Rossum (home page: http://www.python.org/~guido/)