On Friday December 22nd 2006 at 00:37 Junio C Hamano wrote:
> (offtopic) Yeah, but my point was that ANSI C reserves _all_
> symbols that begin with str ("Names reserved for expansion"),
> not just a specific set of functions like strcmp, strcpy, etc.,
> so if a program tries to be compliant with it, it cannot use,
> for example, strncasecmp (was that the symbol we had trouble
> with?) for its own purpose anyway -- which means the system
> header implementation should not have to worry about namespace
> pollution. I do not see any reason for them to hide
> strncasecmp, for example.
(ontopic for offtopic, that makes it still offtopic probably) I think
the intention from Apple might have been to provide a strict least
common denominator environment for developing software that will run
on strictly standardized POSIX standards. Think of someone that has
to develop a program on Darwin and that should also run on OS/400. If
strcasestr(3) isn't in the libraries there it might make some sense to
not make it available in this strict compatibility mode (expose no less
but also no more environment). A sort of combination of '-pedantic' with
'-Werror' as it were. Note that I do not defend it, just trying to find
some sense of logic in it. ;-)
> > On Apple compiling git works fine both with and without
> > _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
> > _XOPEN_SOURCE define which restricts functionality to some predefined
> > set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
> > remove it. So I thought it might be best to keep as much symbols as
> > possible to be the same for all platforms for future expandibility.
> >
> > Probably FreeBSD behaves the same with respect to
> > _XOPEN_SOURCE_EXTENDED. Will check later today.
>
> Ok, thanks.
Checking for compilation with FreeBSD as target should have the macro
"__FreeBSD__" as value. No other value, as already pointed out by Rocco
Rutte.
The behaviour of _XOPEN_SOURCE_EXTENDED on FreeBSD is exactly like on
Apple. This means for git we can either include it or not, it won't make
a difference.
There is a subtle and interesting difference with respect to
the usage of _XOPEN_SOURCE on FreeBSD as compared to Darwin. The only
thing that I see on FreeBSD is that it (indirectly through yet another
macro __XSI_VISIBLE) influences some functions (amongst which
strcasestr(3) in daemon.c) to be declared in the system header
<strings.h> instead of in <string.h>. The FreeBSD header claim that this
should be the POSIX behaviour for _XOPEN_SOURCE. As we do not include
<strings.h> the compilation fails on FreeBSD.
In fact on FreeBSD the problem seems to be only that when _XOPEN_SOURCE
is defined, than the macro __BSD_VISIBLE is unset or 0. Adding just
#ifdef __FreeBSD__
#define __BSD_VISIBLE 1
#endif
before setting _XOPEN_SOURCE in also results in git compiling perfectly
on FreeBSD. In that case for example <string.h> automatically includes
<strings.h>.
So on top of Terjes patch in "master":
diff --git a/git-compat-util.h b/git-compat-util.h
index 41fa7f6..2303951 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,6 +11,10 @@
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+#ifdef __FreeBSD__
+#define __BSD_VISIBLE 1 /* needed in combination with _XOPEN_SOURCE */
+#endif
+
#ifndef __APPLE_CC__
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
--
Marco Roeland
-
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