[Python-Dev] Snake farm
Martin v. Loewis
11 Nov 2002 06:57:48 +0100
Marc Recht <firstname.lastname@example.org> writes:
> > I consider it a bug that FreeBSD does not provide a mode for
> > "Conforming XSI Application Using Extensions", according to
> FreeBSD does support that. _XOPEN_SOURCE = 500 means:
> #define __XSI_VISIBLE 500
> #undef _POSIX_C_SOURCE
> #define _POSIX_C_SOURCE 199506
So how do I request extensions on that system, beyond the functions
defined in XPG/5 or XPG/6?
> > If it is a hack to work around a bug in FreeBSD, then I think it is
> > acceptable.
> I still not think that's a bug in FreeBSD. But I send you sys/cdefs.h
> and unistd.h, so you can have a look for yourself. Maybe I'm getting
> something wrong here. IMO it's just a strict interpretation of the
I have looked at them before, hence my claim that I think FreeBSD has
a bug here.
> Why? There are only two actual changes the case for FreeBSD and the
> addition of _THREAD_SAFE to the CFLAGS if Python is compiled with
> threads. The rest just moves the MACHDEP stuff to the top of
I misread the patch: That it moves the MACHDEP stuff is not visible.
Instead, it moves the --enable-framework stuff downwards.
Still, you add a case with "FreeBSD", and "rest of the world", the
"rest of the world" case being where _GNU_SOURCE, _XOPEN_SOURCE,
_XOPEN_SOURCE_EXTENDED, and _POSIX_C_SOURCE is defined. Why does it
hurt if either _GNU_SOURCE or _XOPEN_SOURCE_EXTENDED would be defined
> > one system" position. Try writing your code in a way so that it
> I don't think so.. Sometimes systems need special treatment...
Only if all other options have been exhausted. What problems occur if
_XOPEN_SOURCE is defined?
> > simultaneously works with many systems, instead of special-casing each
> > system individually.
> I didn't saw an other way to do it. The defines were always set and that
> just doesn't work for FreeBSD.
Did you try defining _GNU_SOURCE and _XOPEN_SOURCE_EXTENDED? I can see
that you don't want _POSIX_C_SOURCE to be defined, either.