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

The latest maintenance release GIT 1.4.4.3 is available at the usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.4.4.3.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.4.4.3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.4.4.3.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.4.4.3-1.$arch.rpm	(RPM)

This release contains merge-recursive corner case fix; it also fixes git-cvsserver (when used with newer Perl) and Mac OS build (when you use config.mak), among other things.

To let people who only follow the 'maint' releases know what's happening in the larger picture...

We have just started talking about the next feature release v1.5.0 on the 'master' branch side. If we are lucky we could do a -rc1 around Christmas, emperor's birthday in Japan, or perhaps emperor's birthday in the Penguin land, but in any case the real release is not expected to happen by mid January.

The new release will have many end-user level changes since the last feature release v1.4.4, both at the UI level and at the documentation level, based on previous discussions on the list.

It is strongly encouraged and very much appreciated to review and to fill gaps you would find in today's 'master' and what's cooking in 'next', if you were involved in the discussions and/or if you are interested in the theme of v1.5.0: "usability and teachability".

Thanks.

-jc.

----------------------------------------------------------------
* The 'maint' branch is at v1.4.4.3 and has these fixes since
  v1.4.4.2:

   Alex Riesen (1):
      Clarify fetch error for missing objects.

   Brian Gernhardt (1):
      Move Fink and Ports check to after config file

   Chris Wright (1):
      no need to install manpages as executable

   Eric Wong (2):
      git-svn: exit with status 1 for test failures
      git-svn: correctly display fatal() error messages

   Jim Meyering (1):
      Don't use memcpy when source and dest. buffers may overlap

   Junio C Hamano (1):
      GIT 1.4.4.3

   Martin Langhoff (1):
      cvsserver: Avoid miscounting bytes in Perl v5.8.x

   Shawn Pearce (2):
      Make sure the empty tree exists when needed in merge-recursive.
      Bypass expensive content comparsion during rename detection.

* The 'master' branch has these since the last announcement.
  They are NOT in 1.4.4.3.

   Aneesh Kumar K.V (1):
      Add config example with respect to branch

   Brian Gernhardt (2):
      Add documentation for show-branch --topics
      Remove COLLISION_CHECK from Makefile since it's not used.

   Eric Wong (1):
      git-cvsserver: fix breakage when calling git merge-file

   Jeff King (1):
      vim syntax: follow recent changes to commit template

   Junio C Hamano (8):
      parse-remote::expand_refs_wildcard()
      show-ref: fix --exclude-existing
      racy-git: documentation updates.
      rerere: fix breakage of resolving.
      fix populate-filespec
      config_rename_section: fix FILE* leak
      simplify inclusion of system header files.
      GIT 1.4.4.3

   Nicolas Pitre (4):
      make patch_delta() error cases a bit more verbose
      make git a bit less cryptic on fetch errors
      index-pack usage of mmap() is unacceptably slower on many OSes
         other than Linux
      clarify some error messages wrt unknown object types

   Robert Fitzsimons (1):
      gitweb: Show '...' links in "summary" view only if there are more items

Junio> * The 'master' branch has these since the last announcement. Junio> They are NOT in 1.4.4.3.

Junio> index-pack usage of mmap() is unacceptably slower on many OSes Junio> other than Linux

Is this really in master? I'm still seeing one-hour times on my Mac, using 8336afa563fbeff35e531396273065161181f04c.

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:

Master right  now is at 54851157ac.

But I use the master site of kernel.org, and the public site mirrors probably haven't mirrored out yet.

Sometimes it can be worth it trying "git2.kernel.org" rather than "git.kernel.org", because the way the DNS round-robin works (badly), git1 seems to get a lot more load than git2, so sometimes git2 gets updated before git1 does.

Linus> Master right  now is at 54851157ac.

Yeah, 54 objects just pulled down.  Here we go.  Time for a test...

Nope... can't compile:

    gcc -o daemon.o -c -g -O2 -Wall  -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
    daemon.c: In function 'parse_extra_args':
    daemon.c:414: warning: implicit declaration of function 'strncasecmp'
    daemon.c: In function 'socksetup':
    daemon.c:766: error: 'NI_MAXSERV' undeclared (first use in this function)
    daemon.c:766: error: (Each undeclared identifier is reported only once
    daemon.c:766: error: for each function it appears in.)
    daemon.c:766: warning: unused variable 'pbuf'
    daemon.c: In function 'serve':
    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?

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

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

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

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

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.

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

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.

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

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:

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

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).

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> 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.

Hi,

20 Dec 2006 15:34:43 -0800, Randal L. Schwartz <merlyn@stonehenge.com>:

Hm, very strange - for me the patch mentioned here works fine. (Mac OS X 10.4.8 on an Intel Mac)

bye

dreamind

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:

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?

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?

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

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.

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:

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

---

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

--

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

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?

On 12/21/06, Junio C Hamano <junkio@cox.net> wrote:

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

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

Thanks for clarifying this; will apply.

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

Junio> Thanks for clarifying this; will apply.

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

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

Won't; thanks for catching me soon enough.

On 20 Dec 2006 17:20:40 -0800, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

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.)

Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of available functions and symbols. This can not be cured by adding extra defines in any way. So there really is only the choice between _not_ defining this symbol on Mac OS X or restricting our usage of functions and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE. The first seems better.

Note the last three lines from this following literal code snippet in /usr/include/sys/cdefs.h from the Apple Darwin sources:

 * By default newly complied code will actually get the same symbols
 * that the old code did.  Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
 * or _POSIX_C_SOURCE will give you the new symbols.  Defining _XOPEN_SOURCE
 * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
 * Apple's APIs.

We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

The preferred way of checking specific Apple specific issues is by using the __APPLE__ predefined macro.

The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers (like the /usr/include/curses.h header) and can stay.

Patch from Terje Sten Bjerkseth, only added a comment.

Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of available functions and symbols. This can not be cured by adding extra defines in any way. So there really is only the choice between _not_ defining this symbol on Mac OS X or restricting our usage of functions and symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE. The first seems better.

Note the last three lines from this following literal code snippet in /usr/include/sys/cdefs.h from the Apple Darwin sources:

 * By default newly complied code will actually get the same symbols
 * that the old code did.  Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,
 * or _POSIX_C_SOURCE will give you the new symbols.  Defining _XOPEN_SOURCE
 * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of
 * Apple's APIs.

We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!

The preferred way of checking specific Apple specific issues is by using the __APPLE__ predefined macro.

The extra define _XOPEN_SOURCE_EXTENDED does only affect some headers (like the /usr/include/curses.h header) and can stay.

FreeBSD 6 requires the __BSD_VISIBLE flag for fchmod(), IPPROTO_IPV6 and more which is only properly set by <sys/cdefs.h> if _POSIX_C_SOURCE isn't present. However, _POSIX_C_SOURCE is defined if _XOPEN_SOURCE is defined and >=500.

As a solution, simply don't define _XOPEN_SOURCE for FreeBSD and continue with its defaults.

Author: Terje Sten Bjerkseth <terje@bjerkseth.org>
Signed-off-by: Rocco Rutte <pdmef@gmx.net>
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
 git-compat-util.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

Marco Roeland <marco.roeland@xs4all.nl> writes:

Personally, I think hiding interfaces such as strXXX and memXXX based on _XOPEN_SOURCE level is already a bug in the system header implementation. The symbols that begin with str are already reserved by the standard and I do not see any point in the system headers to try avoiding namespace contamination.

But we are not in the business of fixing the system headers.

Two and half questions.

 #0.5 Have you checked the tip of 'master' that has Terje's
      patch?  It was reported to work yesterday and that is what
      was committed already.

 #1   __APPLE__ vs __APPLE_CC__ is not something I can decide (I
      do not run a Mac).  If MaxOS is derived from FreeBSD, does
      it by chance define __FreeBSD as well?

 #2   Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
      Mac, but yours doesn't.  Is there a reason that you would
      want '#define _XOPEN_SOURCE_EXTENDED 1'?  Do both FreeBSD
      and Mac behave well with it defined?

Junio C Hamano <junkio@cox.net> wrote:

OK, but that isn't applied in next for some reason.  I'm still
carrying around my own version of Terje's patch.  :-(
 

__FreeBSD doesn't work here on my Mac.

Hi,

* Junio C Hamano [06-12-21 16:52:52 -0800] wrote:

Well, it depends, I'd say. Different strXXX functions may be introduced by different versions of standards and with _POSIX_C_SOURCE one can, for example, define to be compile for a specific standard version only.

First of all, the combined patch posted is wrong since __FreeBSD doesn't work on FreeBSD, but __FreeBSD__ does.

Second, a grep over the FreeBSD headers in /usr/include shows that _XOPEN_SOURCE_EXTENDED only affects 2 curses header files, so it's safe to exclude it, i.e. define it for FreeBSD.

   bye, Rocco

On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:

;-)

Perhaps the idea behind this might be that it allows you to easier develop software that really only uses interfaces strictly defined in some "standards" to be always available on compliant platforms. That's all I could think of why you ever would want to do it like this yes.

For some reason a normal "pull" didn't show this one here yet. But I can see it by merging. The commit "c902c9a" that I now see from Terje does indeed work here. At any rate that one alone doesn't fix the (same) FreeBSD issue as reported by Rocco Rutte who sent in an almost identical patch but with the __FreeBSD__ define.

As far as I know __APPLE__ is the preferred way of finding out we're running for a Darwin target. Someone mentioned that __APPLE_CC__ was not introduced until Apple OS X 10.4. It's value here ('5367') is the build version of the Apple gcc compiler, doesn't seem very standardized. The __APPLE__ macro is defined as '1'.

Unfortunately no there is _not_ any "BSD" like macro defined here, so no __FreeBSD or something. And interesting enough we already know that OpenBSD specifically needs the _XOPEN_SOURCE define. Anyone out there with a NetBSD box so we can fix that as well? ;-)

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.

I don't know if the "Apple Public Source License" allows me to put the Darwin system headers in a publicly accessable place, so I won't do that, but if people are interested I can of course privately provide the system headers and predefined symbols for anyone interested.

Marco Roeland <marco.roeland@xs4all.nl> writes:

(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.

Ok, thanks.

On Friday December 22nd 2006 at 00:37 Junio C Hamano wrote:

(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. ;-)

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":

Hi,

* Marco Roeland [06-12-22 12:47:22 +0100] wrote:

The first patch I sent in did exactly that via -D__BSD_VISIBLE set in the Makefile and Junio correctly complained that the __-prefix is meant to be for internal use only. I bet he'll say the same about this flavour of defining __BSD_VISIBLE. :)

I was just too lazy to recursively go through the #define/#ifdef parts of header files to find why __BSD_VISIBLE is needed.

Second, in <sys/cdefs.h> _XOPEN_SOURCE indirectly influences __BSD_VISIBLE through _POSIX_C_SOURCE. The latter is defined for values of >=500 for _XOPEN_SOURCE so that even

   #define _XOPEN_SOURCE 499

works fine on FreeBSD.

I'm still in favour of simply adding '!defined(__FreeBSD__)' to git-compat-util.h as soon as possible to push out a maintaince release that at least compiles (on FreeBSD)...

   bye, Rocco

On Friday December 22nd 2006 at 12:55 Rocco Rutte wrote:

Agreed. It's the more practical thing to do and Just Works (TM).

Perhaps in the long run we could create platform specific header files to deal with whatever excentricities these provide or need, and include in git-compat-util.h things like for every candidate that needs it:

#ifdef __CrappIX__ #include "compat/crappix.h" #endif

For the _XOPEN_SOURCE specific things it might also be better to reverse the logic, so not exclude it for a number of platforms but only include it for the specific platforms that seem to need it.

So, again on top of Terjes patch in "master":

Junio C Hamano wrote:

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.

On Thu, 21 Dec 2006, Terje Sten Bjerkseth wrote:

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

Your patch is whitespace-damaged, btw.

Linus> Your patch is whitespace-damaged, btw.

The version as an attachment shouldn't have been.

The cut-n-paste might have been.

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

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?

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.

Linus> Master right  now is at 54851157ac.

On a more positive note, with my local (unacceptable) changes to muck with headers, the 54 release does in fact make git-index-pack take under a minute for 313037 objects on OSX. Yeay!

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

I think you are behind rsync mirroring lag.

Look for X-master-at: header in my message to see if you have that commit, please.

Hi,

On Wed, 20 Dec 2006, Junio C Hamano wrote:

Nice!

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Sorry for not advertising. The header has been there for a long time.

On Wed, 20 Dec 2006, Randal L. Schwartz wrote:

It is in current master, but not in 8336afa563fbeff35e5313...

To be sure you have it just open index-pack.c and make sure "mmap" is not found there anymore.

Hi,

On Wed, 20 Dec 2006, Junio C Hamano wrote:

I assume that this line is indented manually, but ...

this is not, in spite of being longer than 76 characters (Do I remember correctly that this supposed to be the maximum length for lines in emails?).

FWIW, I hacked a half-serious patch to wrap the lines automatically:

-- snipsnap -- [FWOT] shortlog: wrap long lines

If a oneline is longer than 76 characters, wrap it and indent with 9 instead of 6 spaces.

For the heck of it, assume UTF-8, and fall back to single-byte
encodings when finding that it cannot be UTF-8. (Not that it makes
a difference if you stick to ASCII.)
---
 builtin-shortlog.c  |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 t/t4201-shortlog.sh |   44 ++++++++++++++++++++++++++++++++++++
 2 files changed, 104 insertions(+), 1 deletions(-)

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

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> -

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.

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

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.

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.

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

Thanks.

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