Marco Roeland <marco.roeland@xxxxxxxxx> writes:
> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!
Personally, I think hiding interfaces such as strXXX and memXXX
based on _XOPEN_SOURCE level is already a bug in the system
header implementation. The symbols that begin with str are
already reserved by the standard and I do not see any point
in the system headers to try avoiding namespace contamination.
But we are not in the business of fixing the system headers.
> The preferred way of checking specific Apple specific issues is by using
> the __APPLE__ predefined macro.
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..6f46f36 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,7 +11,14 @@
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +#if !defined(__APPLE__) && !defined(__FreeBSD)
> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
> +#else
> + /*
> + * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available
> + * functions and symbols.
> + */
> +#endif
> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> #define _GNU_SOURCE
> #define _BSD_SOURCE
Two and half questions.
#0.5 Have you checked the tip of 'master' that has Terje's
patch? It was reported to work yesterday and that is what
was committed already.
#1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I
do not run a Mac). If MaxOS is derived from FreeBSD, does
it by chance define __FreeBSD as well?
#2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
Mac, but yours doesn't. Is there a reason that you would
want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD
and Mac behave well with it defined?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html