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

[François Pinard]

Guido van Rossum <guido@python.org> writes:

> 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 very well understand you, as I was in the same situation not very long
ago, and to be honest, still am...  I had to take a look at this to support
`fnmatch' in Free `paxutils' (formerly GNU `tar'), which support has been
excruciatingly difficult to get right.  I'm not even sure we succeeded, but
I'm not taking care of `tar' matters anymore.  Another case of difficulty
was trying to respond to all user requests about triggering ANSI compilation
whenever the compiler supports it.  For some sensitive systems, the mix of
vendor symbols is extremely important to do correctly, before using their
ANSI compilers.  Moreover, for some vendors, header files are horribly
broken, to the point we just gave up on ANSI compilation.

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

I tried a lot of ways, and this is a sensitive matter on some systems.  As I
did not keep a copy of `tar' sources her, I cannot check what I finally did.
But from memory, I think I managed to define _GNU_SOURCE to 1 if it was
not defined, prior to including any system header file.  Something like:

   #ifndef _GNU_SOURCE
   # define _GNU_SOURCE 1
   #endif

near the beginning of some strategic package header file.  Most probably in
`acconfig.h' for my things, followed by a @TOP@ line to make sure it gets
copied in the generated `config.h'.  If one uses `alloca', one is forced
to include `config.h' very early in his C modules, so I took the habit of
this early inclusion even when I do not use `alloca', making `config.h'
a proper place.  But I do not remember clearly, and checking in the few
packages I still maintain, I do not use _GNU_SOURCE in them.

I presume it worked because no vendors test for _GNU_SOURCE, besides
Linux and, expectedly, the Hurd (which I do not run), or for source files
extracted from the library of those systems, and included within other
packages (surely not the case of Python :-).  My pretesters did not report
problems, but this is not a proof that none exist.  On the other hand, `tar'
was/is a good testbed for portability matters, as many people install it.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard