Re: [BUG] daemon.c blows up on OSX

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
> 
> What I do know is (a) it worked before the header changes and (b)
> the patch I just gave you works.  If the patch doesn't break others,
> can we just leave it in?

Well, at some point it probably _will_ break on other systems, exactly 
because other systems want to have the extended declarations.

It would be much better to have all the weird system dependencies solved 
in ONE place, rather than have each file (depending on just what they 
happen to need) have their own hacks for each weird system header file 
situation.

So it really would be a hell of a lot better to figure out _why_ strings.h 
doesn't "just work" when _XOPEN_SOURCE_EXTENDED is set. Or if there are 
better alternatives that work on HP-UX.. 

Does adding a

	#define _SVID_SOURCE 1

help? Also, we should probably make the _GNU_SOURCE and _BSD_SOURCE 
defines define to 1 (which is the way they'd be if we used -D_GNU_SOURCE 
on the compiler command line)

IOW, the appended ...

The really sad part is that this seems to be an OS X _bug_. 
"strncasecmp()" is part of the standard Open UNIX definitions, it's not 
something that should be shut off by _XOPEN_SOURCE, afaik.

There were apparently some OS X developers on the git list, mind 
commenting on this?

		Linus

---
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..1400905 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -13,8 +13,9 @@
 
 #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 */
-#define _GNU_SOURCE
-#define _BSD_SOURCE
+#define _GNU_SOURCE 1
+#define _BSD_SOURCE 1
+#define _SVID_SOURCE 1
 
 #include <unistd.h>
 #include <stdio.h>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/