From: Marco Roeland <marco.roeland@xs4all.nl>
To: Junio C Hamano <junkio@cox.net>
Cc: Marco Roeland <marco.roeland@xs4all.nl>,
Terje Sten Bjerkseth <terje@bjerkseth.org>,
"Randal L. Schwartz" <merlyn@stonehenge.com>,
Linus Torvalds <torvalds@osdl.org>, Rocco Rutte <pdmef@gmx.net>,
git@vger.kernel.org
Subject: Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
Date: Fri, 22 Dec 2006 12:47:22 +0100 [thread overview]
Message-ID: <20061222114722.GA11274@fiberbit.xs4all.nl> (raw)
In-Reply-To: <7v4pro5nsa.fsf@assigned-by-dhcp.cox.net>
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
next prev parent reply other threads:[~2006-12-22 11:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-20 20:48 What's in git.git (stable), and Announcing GIT 1.4.4.3 Junio C Hamano
2006-12-20 22:04 ` Randal L. Schwartz
2006-12-20 22:14 ` Linus Torvalds
2006-12-20 22:20 ` [BUG] daemon.c blows up on OSX (was Re: What's in git.git (stable), and Announcing GIT 1.4.4.3) Randal L. Schwartz
2006-12-20 22:25 ` [BUG] daemon.c blows up on OSX Junio C Hamano
2006-12-20 22:35 ` Randal L. Schwartz
2006-12-20 22:44 ` Junio C Hamano
2006-12-20 22:46 ` Randal L. Schwartz
2006-12-20 23:03 ` Junio C Hamano
2006-12-20 23:25 ` Randal L. Schwartz
2006-12-20 23:34 ` Randal L. Schwartz
2006-12-21 2:04 ` Stefan Pfetzing
2006-12-20 23:07 ` Linus Torvalds
2006-12-20 23:17 ` Randal L. Schwartz
2006-12-20 23:30 ` Junio C Hamano
2006-12-20 23:41 ` Linus Torvalds
2006-12-21 0:36 ` Terje Sten Bjerkseth
2006-12-21 0:44 ` Junio C Hamano
2006-12-21 0:54 ` Terje Sten Bjerkseth
2006-12-21 1:00 ` Junio C Hamano
2006-12-21 1:20 ` Randal L. Schwartz
2006-12-21 1:29 ` Junio C Hamano
2006-12-21 1:35 ` Terje Sten Bjerkseth
2006-12-21 10:39 ` [PATCH] Do not define _XOPEN_SOURCE on MacOSX as it is too restricting there Marco Roeland
2006-12-21 11:28 ` [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting Marco Roeland
2006-12-22 0:52 ` Junio C Hamano
2006-12-22 1:04 ` Shawn Pearce
2006-12-22 6:53 ` Rocco Rutte
2006-12-22 7:51 ` Marco Roeland
2006-12-22 8:37 ` Junio C Hamano
2006-12-22 11:47 ` Marco Roeland [this message]
2006-12-22 12:55 ` Rocco Rutte
2006-12-22 13:14 ` Marco Roeland
2007-01-03 15:25 ` [BUG] daemon.c blows up on OSX Andreas Ericsson
2006-12-21 0:44 ` Linus Torvalds
2006-12-21 1:07 ` Randal L. Schwartz
2006-12-21 1:13 ` Junio C Hamano
2006-12-21 1:08 ` Randal L. Schwartz
[not found] ` <24BF45E9-DD98-4609-9D65-B01EAA30CCA8@silverinsanity.com>
2006-12-21 1:35 ` Randal L. Schwartz
2006-12-21 1:48 ` Junio C Hamano
2006-12-21 1:50 ` Randal L. Schwartz
2006-12-21 1:57 ` Junio C Hamano
2006-12-20 23:58 ` What's in git.git (stable), and Announcing GIT 1.4.4.3 Randal L. Schwartz
2006-12-20 22:17 ` Junio C Hamano
2006-12-21 8:43 ` Johannes Schindelin
2006-12-21 8:52 ` Junio C Hamano
2006-12-20 22:19 ` Nicolas Pitre
2006-12-21 11:38 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061222114722.GA11274@fiberbit.xs4all.nl \
--to=marco.roeland@xs4all.nl \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=merlyn@stonehenge.com \
--cc=pdmef@gmx.net \
--cc=terje@bjerkseth.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).