public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: merlyn@stonehenge.com (Randal L. Schwartz)
Cc: Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] daemon.c blows up on OSX
Date: Wed, 20 Dec 2006 15:30:50 -0800	[thread overview]
Message-ID: <7v64c65emt.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <86wt4mximh.fsf@blue.stonehenge.com> (Randal L. Schwartz's message of "20 Dec 2006 15:17:10 -0800")

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.



  reply	other threads:[~2006-12-20 23:30 UTC|newest]

Thread overview: 15+ 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:07             ` Linus Torvalds
2006-12-20 23:17               ` Randal L. Schwartz
2006-12-20 23:30                 ` Junio C Hamano [this message]
2006-12-20 23:41                 ` Linus Torvalds
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:19   ` Nicolas Pitre
  -- strict thread matches above, loose matches on Subject: below --
2006-12-21  2:52 [BUG] daemon.c blows up on OSX Albert Cahalan

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v64c65emt.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=merlyn@stonehenge.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox