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

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Nope... can't compile:
> ...
>     daemon.c:970: warning: implicit declaration of function 'initgroups'
>     make: *** [daemon.o] Error 1
>
> This smells like we've seen this before.  Regression introduced with
> some of the cleanup?

Most likely.  You were CC'ed on these messages:

	<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>
	<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>

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

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> Nope... can't compile:
>> ...
>> daemon.c:970: warning: implicit declaration of function 'initgroups'
>> make: *** [daemon.o] Error 1
>> 
>> This smells like we've seen this before.  Regression introduced with
>> some of the cleanup?

Junio> Most likely.  You were CC'ed on these messages:

Junio> 	<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>
Junio> 	<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>

I see in 979e32fa1483a32faa4ec331e29b357e5eb5ef25 that I had to change
some things for OpenBSD... I bet those are generic BSD things.

Lemme see if it breaks on OpenBSD as well.

Oddly enough - it didn't. :)

running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
there on my OSX box.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Lemme see if it breaks on OpenBSD as well.
>
> Oddly enough - it didn't. :)

Of course it didn't.  I was a bit more careful than usual with
this and fired up an OpenBSD bochs on my wife's machine to test
it before pushing out.

> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
> there on my OSX box.

Sorry, I cannot be of immediate help -- I do not have one.

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

[Randal L. Schwartz]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
Randal> there on my OSX box.

According to my headers, "strncasecmp" is defined in <string.h>,
"NI_MAXSERV" is defined in <netdb.h>, and "initgrps" is defined
in "unistd.h".  So this patch works (just verified on OSX), but I
don't know what damage it does elsehwere:

diff --git a/daemon.c b/daemon.c
index b129b83..5ce73ed 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,7 @@
+#include <string.h>
+#include <netdb.h>
+#include <unistd.h>
+
 #include "cache.h"
 #include "pkt-line.h"
 #include "exec_cmd.h"

However, now imap-send.o blows up:

imap-send.c: In function 'imap_open_store':
imap-send.c:908: error: 'AF_LOCAL' undeclared (first use in this function)
imap-send.c:908: error: (Each undeclared identifier is reported only once
imap-send.c:908: error: for each function it appears in.)
imap-send.c:990: warning: implicit declaration of function 'getpass'
imap-send.c:990: warning: assignment makes pointer from integer without a cast
make: *** [imap-send.o] Error 1

and finding "getpass" wants me to add "unistd.h" there too.

Hmm.  Let's see if I can use git-format-patch as Linus intended.


[-- Attachment #2: patch for osx --]
[-- Type: text/plain, Size: 852 bytes --]

From 1549561dc68a1ea71f137c40109c90d33c0f9887 Mon Sep 17 00:00:00 2001
From: Randal L. Schwartz <merlyn@4.sub-70-192-166.myvzw.com>
Date: Wed, 20 Dec 2006 14:45:49 -0800
Subject: [PATCH] patch for osx

---
 daemon.c    |    4 ++++
 imap-send.c |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/daemon.c b/daemon.c
index b129b83..5ce73ed 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,7 @@
+#include <string.h>
+#include <netdb.h>
+#include <unistd.h>
+
 #include "cache.h"
 #include "pkt-line.h"
 #include "exec_cmd.h"
diff --git a/imap-send.c b/imap-send.c
index 894cbbd..afd7447 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -22,6 +22,8 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include <unistd.h>
+
 #include "cache.h"
 
 typedef struct store_conf {
-- 
1.4.4.3.g5485-dirty


[-- Attachment #3: Type: text/plain, Size: 291 bytes --]


-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>
> Randal> running "git version 1.4.4.3.g5485" on my openbsd box, but I can't get
> Randal> there on my OSX box.
>
> According to my headers, "strncasecmp" is defined in <string.h>,
> "NI_MAXSERV" is defined in <netdb.h>, and "initgrps" is defined
> in "unistd.h".  So this patch works (just verified on OSX), but I
> don't know what damage it does elsehwere:
>
> diff --git a/daemon.c b/daemon.c
> index b129b83..5ce73ed 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1,3 +1,7 @@
> +#include <string.h>
> +#include <netdb.h>
> +#include <unistd.h>
> +
>  #include "cache.h"

This unfortunately violates the "all common system headers in
git-compat-util.h" rule, which is needed to define _XOPEN_SOURCE
and friends before including the system header files.

And string.h, netdb.h and unistd.h are already included there,
so there is something deeper going on on OSX.

Is the declaration of strncasecmp in <string.h> on OSX
conditional to some macro (and the same question about other
symbols you did not get)?  We need to find out what feature
macros are expected on that platform and define them as needed.

For example, on OpenBSD, <sys/types.h> does not expose u_int
without __BSD_VISIBLE, and its <netinet/tcp.h> header uses that
type.  The source files (user programs, that's us) are expected
to include sys/types.h before including netinet/tcp.h *AND*
expected to somehow cause __BSD_VISIBLE be defined before
including sys/types.h.  That's why we have _BSD_SOURCE in our
git-compat-util.h header file (_XOPEN_SOURCE and _GNU_SOURCE
serve similar purposes for various other systems).

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

[Linus Torvalds]

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:
> 
> According to my headers, "strncasecmp" is defined in <string.h>,
> "NI_MAXSERV" is defined in <netdb.h>, and "initgrps" is defined
> in "unistd.h".  So this patch works (just verified on OSX), but I
> don't know what damage it does elsehwere:

Look at "cache.h": the first thing it does is to include 
"git-compat-util.h". And THAT in turn does include ALL the headers you 
added (string.h, netdb.h and unistd.h).

So it would appear that for OS X, the

	#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
	#define _GNU_SOURCE
	#define _BSD_SOURCE

sequence actually _disables_ those things.

Some googling finds a python source diff:

	   # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
	   # disables platform specific features beyond repair.
	-  Darwin/8.*)
	+  Darwin/8.*|Darwin/7.*)
	     define_xopen_source=no
	     ;;

(and Ruby shows up as well in the google)

Can you try to grovel around in the OS X headers, and see what the magic 
is to enable all the compatibility crud on OS X?

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

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> 	#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Linus> 	#define _GNU_SOURCE
Linus> 	#define _BSD_SOURCE

Well, _GNU_SOURCE and _BSD_SOURCE only get defined, and only by some
oddballs that aren't relevant here.

Linus> sequence actually _disables_ those things.

Linus> Some googling finds a python source diff:

Linus> 	   # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE
Linus> 	   # disables platform specific features beyond repair.
Linus> 	-  Darwin/8.*)
Linus> 	+  Darwin/8.*|Darwin/7.*)
Linus> 	     define_xopen_source=no
Linus> 	     ;;

Linus> (and Ruby shows up as well in the google)

Linus> Can you try to grovel around in the OS X headers, and see what the magic 
Linus> is to enable all the compatibility crud on OS X?


But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
curses.h.  However, I don't see how that's relevant to strings.h
or the others I need.  There's no "config" for "compatibility".
Welcome to Linux vs Unix. :)

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?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> This unfortunately violates the "all common system headers in
Junio> git-compat-util.h" rule, which is needed to define _XOPEN_SOURCE
Junio> and friends before including the system header files.

Junio> And string.h, netdb.h and unistd.h are already included there,
Junio> so there is something deeper going on on OSX.

Junio> Is the declaration of strncasecmp in <string.h> on OSX
Junio> conditional to some macro (and the same question about other
Junio> symbols you did not get)?  We need to find out what feature
Junio> macros are expected on that platform and define them as needed.

If one of those defines _POSIX_C_SOURCE (or _ANSI_SOURCE),
then <string.h> does *not* define "strncasecmp", because it has those
under a comment of "Nonstandard routines".

Is anything earlier defining one of these?

And yes, netdb.h also has a lot of those depending on _POSIX_C_SOURCE,
and so does unistd.h

So that's your culprit.  You're defining _POSIX_C_SOURCE when you're
not really proper _POSIX_C compliant.  Can you just remove that?

And sys/cdefs.h for darwin has this:

    /* Deal with various X/Open Portability Guides and Single UNIX Spec. */
    #ifdef _XOPEN_SOURCE
    #if _XOPEN_SOURCE - 0L >= 600L
    #undef _POSIX_C_SOURCE
    #define _POSIX_C_SOURCE         200112L
    #elif _XOPEN_SOURCE - 0L >= 500L
    #undef _POSIX_C_SOURCE
    #define _POSIX_C_SOURCE         199506L
    #endif
    #endif

So that's likely how _POSIX_C_SOURCE is getting defined for the rest.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
> curses.h.  However, I don't see how that's relevant to strings.h
> or the others I need.  There's no "config" for "compatibility".
> Welcome to Linux vs Unix. :)
>
> 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?

That would lead to maintenance nightmare in the longer term.  We
cannot do that unless we know more or less what is going on.
Including only some system headers in a random order before
feature macros are defined, and doing so in only some source
files randomly until it starts compiling, is not a solution
maintainable in the longer term.

The _EXTENDED stuff is minimally commented that AIX wants it;
otherwise we would have been tempted to say, "remove it, if it
breaks OSX" without thinking, and would have ended up breaking
AIX.

No matter what we do, I would really want a clear description of
in what way OSX headers are broken and what needs to be done to
avoid the breakage in git-compat-util.h where it sets up feature
macros and includes system headers.

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

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> So that's likely how _POSIX_C_SOURCE is getting defined for the rest.

Unfortunately, just deleting the two _XOPEN_SOURCE entries in
git-compat-util.h doesn't do it, even for OSX.  So something more convoluted
here is going on.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Linus Torvalds]

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>

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

[Terje Sten Bjerkseth]

On 12/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
> 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 ...

For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
causes the NI_MAXSERV problem in netdb.h. The appended seems to make
it work.

--
diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..41fa7f6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,8 +11,10 @@

 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))

+#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 */
+#endif
 #define _GNU_SOURCE

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

[Junio C Hamano]

"Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:

> On 12/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> 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 ...
>
> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
> causes the NI_MAXSERV problem in netdb.h. The appended seems to make
> it work.
>
> --
> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..41fa7f6 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,8 +11,10 @@
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +#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 */
> +#endif
> #define _GNU_SOURCE
> #define _BSD_SOURCE

Thanks.  While this is in a better direction than randomly
including the headers in the source, it is still sad.

Does everybody use Apple CC on OSX?  Is the symbol defined even
with GCC?  Or Gcc fixes headers well enough and makes this a
non-issue?

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

[Linus Torvalds]

On Thu, 21 Dec 2006, Terje Sten Bjerkseth wrote:
> 
> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which
> causes the NI_MAXSERV problem in netdb.h. The appended seems to make
> it work.

Ok, that's probably the best we can do. Along with perhaps cursing at 
apple a bit.

Your patch is whitespace-damaged, btw.

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

[Terje Sten Bjerkseth]

On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
> Thanks.  While this is in a better direction than randomly
> including the headers in the source, it is still sad.
>
> Does everybody use Apple CC on OSX?  Is the symbol defined even
> with GCC?  Or Gcc fixes headers well enough and makes this a
> non-issue?

I'm not sure about everybody, but at least the Apple CC *is* GCC:

~/src/git terjesb$ cc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.

so this is probably a non-issue for default setups. (Sorry about the

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

[Brian Gernhardt]

(I originally forgot to send this to the list.  Oops.  Difference  
between "Reply" and "Reply All" is small, but important.)

On Dec 20, 2006, at 7:44 PM, Junio C Hamano wrote:

> Does everybody use Apple CC on OSX?  Is the symbol defined even
> with GCC?  Or Gcc fixes headers well enough and makes this a
> non-issue?

Apple CC == gcc, as far as I can tell.  And the definition of  
_POSIX_C_SOURCE, which seems to disable too much stuff, is in /usr/ 
include/sys/cdefs.h:

/* Deal with various X/Open Portability Guides and Single UNIX Spec. */
#ifdef _XOPEN_SOURCE
#if _XOPEN_SOURCE - 0L >= 600L
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE     200112L
#elif _XOPEN_SOURCE - 0L >= 500L
#undef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE     199506L
#endif
#endif

Why _POSIX_C_SOURCE disables strncasecmp, I don't know.  It makes me  
sad.

Yours,

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

[Junio C Hamano]

"Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:

> On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
>> Thanks.  While this is in a better direction than randomly
>> including the headers in the source, it is still sad.
>>
>> Does everybody use Apple CC on OSX?  Is the symbol defined even
>> with GCC?  Or Gcc fixes headers well enough and makes this a
>> non-issue?
>
> I'm not sure about everybody, but at least the Apple CC *is* GCC:

Thanks for clarifying this; will apply.

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

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> Your patch is whitespace-damaged, btw.

The version as an attachment shouldn't have been.

The cut-n-paste might have been.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Randal L. Schwartz]

>>>>> "Terje" == Terje Sten Bjerkseth <terje@bjerkseth.org> writes:


Terje> +#ifndef __APPLE_CC__
Terje>  #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD
Terje> needs 600 for S_ISLNK() */
Terje>  #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Terje> +#endif
Terje>  #define _GNU_SOURCE
Terje>  #define _BSD_SOURCE
Terje> -

I tried the moral equivalent of that, and it failed to compile many
other things then.  So that's not it.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>
> Linus> Your patch is whitespace-damaged, btw.
>
> The version as an attachment shouldn't have been.
>
> The cut-n-paste might have been.

While I do not have a clue on what point you are trying to make,
I have a more important question for you.

Does Terje's patch fix it for you?

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

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> "Terje Sten Bjerkseth" <terje@bjerkseth.org> writes:
>> On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:
>>> Thanks.  While this is in a better direction than randomly
>>> including the headers in the source, it is still sad.
>>> 
>>> Does everybody use Apple CC on OSX?  Is the symbol defined even
>>> with GCC?  Or Gcc fixes headers well enough and makes this a
>>> non-issue?
>> 
>> I'm not sure about everybody, but at least the Apple CC *is* GCC:

Junio> Thanks for clarifying this; will apply.

But don't because it doesn't help. :(

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>> I'm not sure about everybody, but at least the Apple CC *is* GCC:
>
> Junio> Thanks for clarifying this; will apply.
>
> But don't because it doesn't help. :(

Won't; thanks for catching me soon enough.

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

[Terje Sten Bjerkseth]

On 20 Dec 2006 17:20:40 -0800, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> Thanks for clarifying this; will apply.
>
> But don't because it doesn't help. :(

It definitely works here with it. This is on Mac OS X 10.4.8 (Intel)
with default GCC 4.0.1 from Developer Tools.

Which version are you using? Does it work if you change from testing
__APPLE_CC__ to just __APPLE__? That also works here, and is probably
better anyway. (Perhaps you are using an earlier version and the
former define was introduced with gcc 4.0 to separate gcc compiler
versions.)

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

[Randal L. Schwartz]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

>>>>> "Brian" == Brian Gernhardt <benji@silverinsanity.com> writes:

Brian> On Dec 20, 2006, at 8:08 PM, Randal L. Schwartz wrote:

>>>>>>> "Terje" == Terje Sten Bjerkseth <terje@bjerkseth.org> writes:
>> 
>> 
Terje> +#ifndef __APPLE_CC__
Terje> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500,  OpenBSD
Terje> needs 600 for S_ISLNK() */
Terje> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Terje> +#endif
Terje> #define _GNU_SOURCE
Terje> #define _BSD_SOURCE
Terje> -
>> 
>> I tried the moral equivalent of that, and it failed to compile many
>> other things then.  So that's not it.

Brian> Well, it seems to work for me as is (although I applied it manually  instead
Brian> of dealing with copy/paste with a patch).

I did it with #if 0 / #end instead of the __APPLE_CC__ symbol.
But, weirdly, now that I used the symbol, I get a good compile.

Does #if 0 not work? :)

Sorry for being objectionable earlier then.  I've attached the precise
patch I used and works and verified.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[-- Attachment #2: 0001-patch-from-email.txt --]
[-- Type: text/plain, Size: 727 bytes --]

>From 9e3f88df3f6b17804f53fb497202f0879ea5e5f3 Mon Sep 17 00:00:00 2001
From: Randal L. Schwartz <merlyn@stonehenge.com>
Date: Wed, 20 Dec 2006 17:32:21 -0800
Subject: [PATCH] patch-from-email

---
 git-compat-util.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/git-compat-util.h b/git-compat-util.h
index bc296b3..41fa7f6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -11,8 +11,10 @@
 
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 
+#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 */
+#endif
 #define _GNU_SOURCE
 #define _BSD_SOURCE
 
-- 
1.4.4.3.g9e3f8

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>> I tried the moral equivalent of that, and it failed to compile many
>>> other things then.  So that's not it.
> ...
> I did it with #if 0 / #end instead of the __APPLE_CC__ symbol.
> But, weirdly, now that I used the symbol, I get a good compile.
> ...
> Sorry for being objectionable earlier then.  I've attached the precise
> patch I used and works and verified.

Just to make sure... the attached looks exactly what Terje's
patch would have been before the whitespace damage.  Can I take
this as confirmation that the patch works for you and Terje?

I wonder what the earlier failure you got from "the moral
equivalent" was -- I hope it is not an indication that we have a
dependency bug in our Makefile somewhere.

Thanks.

> diff --git a/git-compat-util.h b/git-compat-util.h
> index bc296b3..41fa7f6 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -11,8 +11,10 @@
>  
>  #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>  
> +#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 */
> +#endif
>  #define _GNU_SOURCE
>  #define _BSD_SOURCE
>  
> -- 
> 1.4.4.3.g9e3f8

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

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> Just to make sure... the attached looks exactly what Terje's
Junio> patch would have been before the whitespace damage.  Can I take
Junio> this as confirmation that the patch works for you and Terje?

The patch I uploaded should be character-equivalent to Terje's.
I don't know what "whitespace damage" you're referencing.

Junio> I wonder what the earlier failure you got from "the moral
Junio> equivalent" was -- I hope it is not an indication that we have a
Junio> dependency bug in our Makefile somewhere.

Yeah, I'm not sure why

#if 0
those two defines
#end

doesn't do the same thing.  Oh well, shrug.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> The patch I uploaded should be character-equivalent to Terje's.

Thanks.

> I don't know what "whitespace damage" you're referencing.

Aha, it was undamaged but rendered as if it were, because it was
of "content-type: text/plain; format=flawed".

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

[Albert Cahalan]

Linus Torvalds writes:

> So it would appear that for OS X, the
>
>       #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
>       #define _GNU_SOURCE
>       #define _BSD_SOURCE
> sequence actually _disables_ those things.

Yes, of course. The odd one here is glibc.

Normal systems enable everything by default. As soon as you
specify a feature define, you get ONLY what you asked for.
I'm not sure why glibc is broken, but I suspect that somebody
wants to make everyone declare their code to be GNU source.
(despite many "GNU" things not working on the HURD at all)

Define _APPLE_C_SOURCE to make MacOS X give you everything.

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

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> Does everybody use Apple CC on OSX?  Is the symbol defined even
> with GCC?  Or Gcc fixes headers well enough and makes this a
> non-issue?
> 

Just for future reference

http://predef.sourceforge.net/preos.html

holds a pretty complete list of identifying macros for more kinds of 
systems than I've had the questionable privilege of having to work with. 
I've used it pretty extensively when trying to write portable code, 
since I too have a hard time liking autoconf and friends.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231