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

From: Linus Torvalds
Date: Wed Dec 20 2006 - 18:41:57 EST




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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/