{"thread":{"id":"27454","subject":"[PATCH 1/2] Add additional build options for Interix, and remove obsolete ones.","startedAt":"2011-05-25T14:15:22Z","lastAt":"2011-06-15T11:34:18Z","messageCount":18,"participants":["mduft@gentoo.org","Junio C Hamano","Tor Arntsen","Erik Faye-Lund","Jonathan Nieder","Markus Duft"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"168662","messageId":"1306332924-28587-1-git-send-email-mduft@gentoo.org","threadId":"27454","inReplyTo":null,"subject":"[PATCH] Interix catch-ups for recent changes/releases.","fromName":"","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-25T14:15:22Z","receivedAt":"2011-05-25T14:15:22Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"\nHey!\n\nSince it has been a while since i last built git on interix, it didn't work out of the box for older interixen.\nThere are a few small changes required, which i hope should be not a big thing to get included in the git repo.\n\nThe removal of two previously required options from the Makefile is because of a special library (libsuacomp: [1]).\nThis library is required all over the place on interix, and provides those previously missing things. There are\nothers depending on this (gnulib, findutils, coreutils, ...) for interix support, and thus i think it should not \nbe a problem to depend on it, right?\n\nMay i ask for a review?\n\nThanks,\nmarkus\n"},{"id":"168660","messageId":"1306332924-28587-2-git-send-email-mduft@gentoo.org","threadId":"27454","inReplyTo":"1306332924-28587-1-git-send-email-mduft@gentoo.org","subject":"[PATCH 1/2] Add additional build options for Interix, and remove obsolete ones.","fromName":"","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-25T14:15:23Z","receivedAt":"2011-05-25T14:15:23Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"Interix versions older than 6.0 (so 3.5 and 5.2) both lack\nstruct sockaddr_storage and the FNM_CASEFOLD GNU extension,\nso disable them both.\n\nThe removed options are obsolete, because interix support now\ndepends on libsuacomp.\n\nSigned-off-by: Markus Duft \n---\n Makefile | 6 ++++--\n 1 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex db72c45..c47cd4e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1113,8 +1113,6 @@ endif\n \tX = .exe\n endif\n ifeq ($(uname_S),Interix)\n-\tNO_SYS_POLL_H = YesPlease\n-\tNO_INTTYPES_H = YesPlease\n \tNO_INITGROUPS = YesPlease\n \tNO_IPV6 = YesPlease\n \tNO_MEMMEM = YesPlease\n@@ -1125,10 +1123,14 @@ ifeq ($(uname_S),Interix)\n \tifeq ($(uname_R),3.5)\n \t\tNO_INET_NTOP = YesPlease\n \t\tNO_INET_PTON = YesPlease\n+\t\tNO_SOCKADDR_STORAGE = YesPlease\n+\t\tNO_FNMATCH_CASEFOLD = YesPlease\n \tendif\n \tifeq ($(uname_R),5.2)\n \t\tNO_INET_NTOP = YesPlease\n \t\tNO_INET_PTON = YesPlease\n+\t\tNO_SOCKADDR_STORAGE = YesPlease\n+\t\tNO_FNMATCH_CASEFOLD = YesPlease\n \tendif\n endif\n ifneq (,$(findstring MINGW,$(uname_S)))\n-- \n1.7.3.4\n"},{"id":"168661","messageId":"1306332924-28587-3-git-send-email-mduft@gentoo.org","threadId":"27454","inReplyTo":"1306332924-28587-1-git-send-email-mduft@gentoo.org","subject":"[PATCH 2/2] Include unistd.h.","fromName":"","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-25T14:15:24Z","receivedAt":"2011-05-25T14:15:24Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"At least on Interix, NULL is defined in unistd.h, and not including it\ncauses compilation failure.\n\nSigned-off-by: Markus Duft \n---\n compat/fnmatch/fnmatch.c | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\nindex 14feac7..0238cca 100644\n--- a/compat/fnmatch/fnmatch.c\n+++ b/compat/fnmatch/fnmatch.c\n@@ -25,6 +25,7 @@\n # define _GNU_SOURCE\t1\n #endif\n \n+#include \n #include \n #include \n #include \n-- \n1.7.3.4\n"},{"id":"168692","messageId":"7vhb8i4qja.fsf@alter.siamese.dyndns.org","threadId":"27454","inReplyTo":"1306332924-28587-2-git-send-email-mduft@gentoo.org","subject":"Re: [PATCH 1/2] Add additional build options for Interix, and remove obsolete ones.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T17:51:37Z","receivedAt":"2011-05-25T17:51:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"mduft@gentoo.org writes:\n\n> Interix versions older than 6.0 (so 3.5 and 5.2) both lack\n> struct sockaddr_storage and the FNM_CASEFOLD GNU extension,\n> so disable them both.\n>\n> The removed options are obsolete, because interix support now\n> depends on libsuacomp.\n\nand linkage with -lsuacomp happens automatically without any change in the\nMakefile for anybody? Just asking, as I do not have an access to (nor any\nparticular desire to get an access to) an Interix to figure it out myself,\nand the only think I care about in this patch is if it helps only your\ninstallation or it will help everybody who has Interix but not necessarily\nwith the same set of additional configuration as you have.\n\n> Signed-off-by: Markus Duft \n> ---\n> Makefile | 6 ++++--\n> 1 files changed, 4 insertions(+), 2 deletions(-)\n>\n> diff --git a/Makefile b/Makefile\n> index db72c45..c47cd4e 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -1113,8 +1113,6 @@ endif\n> \tX = .exe\n> endif\n> ifeq ($(uname_S),Interix)\n> -\tNO_SYS_POLL_H = YesPlease\n> -\tNO_INTTYPES_H = YesPlease\n> \tNO_INITGROUPS = YesPlease\n> \tNO_IPV6 = YesPlease\n> \tNO_MEMMEM = YesPlease\n> @@ -1125,10 +1123,14 @@ ifeq ($(uname_S),Interix)\n> \tifeq ($(uname_R),3.5)\n> \t\tNO_INET_NTOP = YesPlease\n> \t\tNO_INET_PTON = YesPlease\n> +\t\tNO_SOCKADDR_STORAGE = YesPlease\n> +\t\tNO_FNMATCH_CASEFOLD = YesPlease\n> \tendif\n> \tifeq ($(uname_R),5.2)\n> \t\tNO_INET_NTOP = YesPlease\n> \t\tNO_INET_PTON = YesPlease\n> +\t\tNO_SOCKADDR_STORAGE = YesPlease\n> +\t\tNO_FNMATCH_CASEFOLD = YesPlease\n> \tendif\n> endif\n> ifneq (,$(findstring MINGW,$(uname_S)))\n"},{"id":"168698","messageId":"7vd3j64oq6.fsf@alter.siamese.dyndns.org","threadId":"27454","inReplyTo":"1306332924-28587-3-git-send-email-mduft@gentoo.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T18:30:41Z","receivedAt":"2011-05-25T18:30:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"mduft@gentoo.org writes:\n\n> At least on Interix, NULL is defined in unistd.h, and not including it\n> causes compilation failure.\n>\n> Signed-off-by: Markus Duft \n> ---\n> compat/fnmatch/fnmatch.c | 1 +\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n>\n> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\n> index 14feac7..0238cca 100644\n> --- a/compat/fnmatch/fnmatch.c\n> +++ b/compat/fnmatch/fnmatch.c\n> @@ -25,6 +25,7 @@\n> # define _GNU_SOURCE\t1\n> #endif\n> \n> +#include \n> #include \n> #include \n> #include \n\nThe header stddef.h is where NULL is supposed to be defined, and commonly\nused headers are supposed to define NULL the same way as stddef.h does.\nThere is a conditional inclusion of stdlib.h in fnmatch.c and stdlib.h is\none of those files; probably that is how the upstream pulls in NULL when\ncompiling this.\n\nBut we don't define STDC_HEADERS nor _LIBC (and we shouldn't), so I don't\nknow how the existing users of compat/fnmatch/ gets the defintion of NULL\nfrom. Output from \"gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c\" does\nnot seem to show any NULL defined.\n\nOther platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD\nand compile this file. How are they getting their NULLs?\n"},{"id":"168715","messageId":"BANLkTim4gPAyA9vLnpBz7qRY+b4RQ7LwNw@mail.gmail.com","threadId":"27454","inReplyTo":"7vd3j64oq6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2011-05-25T20:37:34Z","receivedAt":"2011-05-25T20:37:34Z","isPatch":true,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Wed, May 25, 2011 at 20:30, Junio C Hamano wrote:\n> mduft@gentoo.org writes:\n>\n>> At least on Interix, NULL is defined in unistd.h, and not including it\n>> causes compilation failure.\n>>\n>> Signed-off-by: Markus Duft \n>> ---\n>>  compat/fnmatch/fnmatch.c |    1 +\n>>  1 files changed, 1 insertions(+), 0 deletions(-)\n>>\n>> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\n>> index 14feac7..0238cca 100644\n>> --- a/compat/fnmatch/fnmatch.c\n>> +++ b/compat/fnmatch/fnmatch.c\n>> @@ -25,6 +25,7 @@\n>>  # define _GNU_SOURCE 1\n>>  #endif\n>>\n>> +#include \n>>  #include \n>>  #include \n>>  #include \n>\n> The header stddef.h is where NULL is supposed to be defined, and commonly\n> used headers are supposed to define NULL the same way as stddef.h does.\n> There is a conditional inclusion of stdlib.h in fnmatch.c and stdlib.h is\n> one of those files; probably that is how the upstream pulls in NULL when\n> compiling this.\n\nAccording to POSIX (well, IEEE Std 1003.1, 2004 Edition at least)\nunistd.h must define NULL:\n\n\"\nThe following symbolic constant shall be defined:\n\nNULL\n Null pointer\n\"\n\n> But we don't define STDC_HEADERS nor _LIBC (and we shouldn't), so I don't\n> know how the existing users of compat/fnmatch/ gets the defintion of NULL\n> from. Output from \"gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c\" does\n> not seem to show any NULL defined.\n>\n> Other platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD\n> and compile this file.  How are they getting their NULLs?\n\nIRIX defines NULL in and (the latter via\n).\nSolaris 10 defines NULL in , but also in via\n\nTru64 v5.1 in and and a bunch of other places\n(string.h, stdio,h, stdlib.h, everywhere)\nAIX 5.1 in and and just about everywhere.\nLinux also gets NULL via because it includes ,\nbut then stddef.h isn't in /usr/include, at least on my system -\npresumably it's in some compiler-provided place.\n\nFor all those non-Linu systems it's always a straight-forward no-dependency\n#ifndef NULL\n#define NULL 0 /* or sometimes 0L */\n#endif\n\n-Tor\n"},{"id":"168717","messageId":"7vvcwy1onq.fsf@alter.siamese.dyndns.org","threadId":"27454","inReplyTo":"BANLkTim4gPAyA9vLnpBz7qRY+b4RQ7LwNw@mail.gmail.com","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T21:00:25Z","receivedAt":"2011-05-25T21:00:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tor Arntsen writes:\n\n> On Wed, May 25, 2011 at 20:30, Junio C Hamano wrote:\n> ...\n>> The header stddef.h is where NULL is supposed to be defined, and commonly\n>> used headers are supposed to define NULL the same way as stddef.h does.\n>> There is a conditional inclusion of stdlib.h in fnmatch.c and stdlib.h is\n>> one of those files; probably that is how the upstream pulls in NULL when\n>> compiling this.\n>\n> According to POSIX (well, IEEE Std 1003.1, 2004 Edition at least)\n> unistd.h must define NULL:\n\nYes, unistd.h is also one of the common header files just like stdlib.h and\nstdio.h that are required to define NULL the same way as stddef.h does.\n\nCf.\n http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html\n\n>> Other platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD\n>> and compile this file.  How are they getting their NULLs?\n>\n> IRIX defines NULL in ...\n> ... presumably it's in some compiler-provided place.\n\nYes, but that still does not explain where compat/fnmatch/fnmatch.c gets\nits NULL from.\n\n> #ifndef NULL\n> #define NULL 0 /* or sometimes 0L */\n> #endif\n\nYou probably would want to say \"(void *) 0\" if you quote POSIX in the same\nmessage ;-).\n\nCf.\n http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stddef.h.html\n\nTo recap my original question that is not unanswered, the current codebase\ndoes not include unistd.h nor stddef.h when compiling the compatibility\nfnmatch.c source we borrowed from glibc, but nobody seems to have\ncomplained that it does not compile due to the lack of NULL, so they must\nbe getting their NULL from somewhere already, but I couldn't find where.\nThat is what I was wondering.\n"},{"id":"168722","messageId":"BANLkTi=w1hpmrK8_Vv8vTLtDF+qf6cETEw@mail.gmail.com","threadId":"27454","inReplyTo":"7vd3j64oq6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-05-25T21:52:44Z","receivedAt":"2011-05-25T21:52:44Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, May 25, 2011 at 8:30 PM, Junio C Hamano wrote:\n> mduft@gentoo.org writes:\n>\n>> At least on Interix, NULL is defined in unistd.h, and not including it\n>> causes compilation failure.\n>>\n>> Signed-off-by: Markus Duft \n>> ---\n>>  compat/fnmatch/fnmatch.c |    1 +\n>>  1 files changed, 1 insertions(+), 0 deletions(-)\n>>\n>> diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\n>> index 14feac7..0238cca 100644\n>> --- a/compat/fnmatch/fnmatch.c\n>> +++ b/compat/fnmatch/fnmatch.c\n>> @@ -25,6 +25,7 @@\n>>  # define _GNU_SOURCE 1\n>>  #endif\n>>\n>> +#include \n>>  #include \n>>  #include \n>>  #include \n>\n> The header stddef.h is where NULL is supposed to be defined, and commonly\n> used headers are supposed to define NULL the same way as stddef.h does.\n> There is a conditional inclusion of stdlib.h in fnmatch.c and stdlib.h is\n> one of those files; probably that is how the upstream pulls in NULL when\n> compiling this.\n>\n> But we don't define STDC_HEADERS nor _LIBC (and we shouldn't), so I don't\n> know how the existing users of compat/fnmatch/ gets the defintion of NULL\n> from. Output from \"gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c\" does\n> not seem to show any NULL defined.\n>\n> Other platforms (e.g. SunOS, IRIX, HPUX, Windows) use NO_FNMATCH_CASEFOLD\n> and compile this file.  How are they getting their NULLs?\n\nWindows/MinGW:\n\n$ gcc -E -dD -DNO_FNMATCH compat/fnmatch/fnmatch.c | grep NULL\ncompat/fnmatch/fnmatch.c:29:21: error: fnmatch.h: No such file or directory\n#define __MINGW_ATTRIB_NONNULL(arg) __attribute__ ((__nonnull__ (arg)))\n#undef __need_NULL\n#define __need_NULL\n#undef NULL\n#define NULL ((void *)0)\n#undef __need_NULL\n\nThe \"#define NULL ((void *)0)\"-line comes from stddef.h, which is\nincluded from string.h, which in turn is included by fnmatch.c.\n"},{"id":"168741","messageId":"20110526022045.GA8172@elie","threadId":"27454","inReplyTo":"1306332924-28587-3-git-send-email-mduft@gentoo.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-26T02:20:45Z","receivedAt":"2011-05-26T02:20:45Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nmduft@gentoo.org wrote:\n\n> --- a/compat/fnmatch/fnmatch.c\n> +++ b/compat/fnmatch/fnmatch.c\n> @@ -25,6 +25,7 @@\n> # define _GNU_SOURCE\t1\n> #endif\n> \n> +#include \n> #include \n\nGiven that we are touching this file anyway, how about relying on\ngit-compat-util for this?\n\nThat way, there is no need to debug feature test macros, order of\n#includes, etc. Untested.\n\n-- >8 --\nSubject: compat/fnmatch: use git-compat-util.h for system headers\n\nFinding the right feature test macros and ordering of #includes to\nget the desired functionality from all operating systems can be a big\npain. Take advantage of the debugging already done and avoid future\nchurn by using git's usual git-compat-util for this.\n\nIn particular, the current fnmatch.c doesn't #include anything that\nought to provide NULL unless HAVE_STRING_H is defined, and it fails to\ncompile on Interix because of this. Other platforms must have been\ngetting the macro through another header.\n\nTo make this code easier to reuse and to simplify future automated\nmerges from upstream, still keep the old #includes, just disabled with\n\"#if 0\".\n\nReported-by: Markus Duft \nSigned-off-by: Jonathan Nieder \n---\nMaybe the old #includes after #include-ing git-compat-util should be\nleft uncommented because harmless.\n\n compat/fnmatch/fnmatch.c | 4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\nindex 14feac7..4bf3b5c 100644\n--- a/compat/fnmatch/fnmatch.c\n+++ b/compat/fnmatch/fnmatch.c\n@@ -16,6 +16,9 @@\n write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,\n Boston, MA 02111-1307, USA. */\n \n+#include \"git-compat-util.h\"\n+\n+#if 0\n #if HAVE_CONFIG_H\n # include \n #endif\n@@ -46,6 +49,7 @@\n # include \n # include \n #endif\n+#endif\n \n /* Comment out all this code if we are using the GNU C Library, and are not\n actually compiling the library itself. This code is part of the GNU C\n-- \n1.7.5.1\n"},{"id":"168752","messageId":"4DDDF339.4000703@gentoo.org","threadId":"27454","inReplyTo":"1306332924-28587-2-git-send-email-mduft@gentoo.org","subject":"Re: [PATCH 1/2] Add additional build options for Interix, and remove obsolete ones.","fromName":"Markus Duft","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-26T06:29:13Z","receivedAt":"2011-05-26T06:29:13Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"On 05/25/11 16:15, mduft@gentoo.org wrote:\n\n(sorry for actually replying to the wrong mail - wasn't subscribed to the list (but am now.))\n\n>> The removed options are obsolete, because interix support now\n>> depends on libsuacomp.\n>\n> and linkage with -lsuacomp happens automatically without any change in the\n> Makefile for anybody? Just asking, as I do not have an access to (nor any\n> particular desire to get an access to) an Interix to figure it out myself,\n> and the only think I care about in this patch is if it helps only your\n> installation or it will help everybody who has Interix but not necessarily\n> with the same set of additional configuration as you have.\n\nYes. suacomp installs itself as libc.{a,so}. Of course the path to the suacomp prefix needs to be told to the compiler. Without it, interix (at least the newer versions) are near unusable, because of a whole lot of bugs M$ won't fix (as usual...). Suacomp can be installed manually by whoever likes to, and is included in the Gentoo Prefix project automatically (which is my target). I guess without Gentoo Prefix there'd be another whole lot of things missing to build git anyway (haven't tried). Gentoo Prefix also automatically get's all paths right, etc.\n\nCurrently, suacomp is already required for things like coreutils, perl, python, openssh, findutils, etc., etc. to work correctly, if not build at all...\n\nHope that explains some, sorry for not doing so at first :)\n\nRegards, Markus\n\n>\n>> Signed-off-by: Markus Duft gentoo.org>\n"},{"id":"168779","messageId":"7vhb8hzcm8.fsf@alter.siamese.dyndns.org","threadId":"27454","inReplyTo":"20110526022045.GA8172@elie","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-26T15:48:47Z","receivedAt":"2011-05-26T15:48:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Given that we are touching this file anyway, how about relying on\n> git-compat-util for this?\n\nMany files in compat/ implementation already includes this header, so it\nlogically feels like a sane thing to do. I vaguely recall there was one\ncorner case where we didn't want to do this, but I do not remember the\ndetails.\n\nBut I am tempted to do the following, as Tor Arntsen suggested, which I\nthink is the least risky solution. I deliberately spelled \"0\" without the\n(void *) pointer cast, as this code borrowed from upstream is in old K&R\nstyle and nobody talks about \"void\" elsewhere in the code.\n\n compat/fnmatch/fnmatch.c | 4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch.c\nindex 14feac7..9473aed 100644\n--- a/compat/fnmatch/fnmatch.c\n+++ b/compat/fnmatch/fnmatch.c\n@@ -127,6 +127,10 @@ extern char *getenv ();\n extern int errno;\n # endif\n \n+# ifndef NULL\n+# define NULL 0\n+# endif\n+\n /* This function doesn't exist on most systems. */\n \n # if !defined HAVE___STRCHRNUL && !defined _LIBC\n"},{"id":"168800","messageId":"20110526163921.GD24931@elie","threadId":"27454","inReplyTo":"7vhb8hzcm8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-26T16:39:21Z","receivedAt":"2011-05-26T16:39:21Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> --- a/compat/fnmatch/fnmatch.c\n> +++ b/compat/fnmatch/fnmatch.c\n> @@ -127,6 +127,10 @@ extern char *getenv ();\n> extern int errno;\n> # endif\n> +\n> +# ifndef NULL\n> +# define NULL 0\n> +# endif\n\nMakes a lot of sense. This fits well with the style of the rest of\nthe file and other projects using glibc fnmatch could reuse the fix\neven if targeting ancient platforms.\n"},{"id":"168807","messageId":"7vboypxrp3.fsf@alter.siamese.dyndns.org","threadId":"27454","inReplyTo":"4DDDF339.4000703@gentoo.org","subject":"Re: [PATCH 1/2] Add additional build options for Interix, and remove obsolete ones.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-26T18:06:00Z","receivedAt":"2011-05-26T18:06:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Markus Duft writes:\n\n> On 05/25/11 16:15, mduft@gentoo.org wrote:\n>\n> (sorry for actually replying to the wrong mail - wasn't subscribed to the list (but am now.))\n>\n>>> The removed options are obsolete, because interix support now\n>>> depends on libsuacomp.\n>>\n>> and linkage with -lsuacomp happens automatically without any change in the\n>> Makefile for anybody? Just asking, as I do not have an access to (nor any\n>> particular desire to get an access to) an Interix to figure it out myself,\n>> and the only think I care about in this patch is if it helps only your\n>> installation or it will help everybody who has Interix but not necessarily\n>> with the same set of additional configuration as you have.\n>\n> Yes. suacomp installs itself as libc.{a,so}. Of course the path to the\n> suacomp prefix needs to be told to the compiler. Without it, interix (at\n> least the newer versions) are near unusable,...\n\nYou are much more familiar with Interix than I am, and if you were the\nonly person who uses Interix with git, I would buy that argument\nunconditionally.\n\nHow has one built and used git before suacomp days? Are these users\nextinct? Are there users who do not still use suacomp and for whatever\nreason do not want to use it, but still want to use git?\n\nWhat I am getting at is that I have to come up with a description in the\nrelease notes, and I cannot decide what the entry for this change should\nsay, and if I can stand behind that statement.\n\nHere is one version, based on my reading of what you said so far:\n\n * The build procedure for Interix now requires use of suacomp. Older\n versions of Interix that are incompatible with suacomp are no longer\n supported. The Makefile does not automatically tell \"the path to the\n suacomp prefix\" to the compiler, so you would need to do that yourself.\n\nDoesn't sound pretty, and I hesitate to stand behind such a statement.\nAbandoning obsoleted versions of obscure platform nobody cares about is\nfine, but at least we should make it clear who are being abandoned by\nsaying which version. Also \"needs to be told to the compiler\" part needs\nsome end-user explanation in Makefile (\"set HAVE_SUACOMP=/usr/lib/suacomp\nwhen building on/for Interix\", or something).\n\nHere is another possible version (you would need to update your patch to\nsupport both):\n\n * On Interix, it is preferrable to use suacomp to build git, but the old\n way is still supported. Give HAVE_SUACOMP=/path/to/suacomp to Make (or\n override it in your config.mak) when building git.\n\nThat is more easily justifiable, but I cannot tell from this exchange with\nyou how important to keep supporting the old way is (or if it is even\npossible).\n"},{"id":"168854","messageId":"4DDF4440.4040405@gentoo.org","threadId":"27454","inReplyTo":"1306332924-28587-3-git-send-email-mduft@gentoo.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Markus Duft","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-27T06:27:12Z","receivedAt":"2011-05-27T06:27:12Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"(still not getting mail from the list, so copied from the archive...).\n\n> Markus Duft gentoo.org> writes:\n> \n[snip]\n>>\n>> Yes. suacomp installs itself as libc.{a,so}. Of course the path to the\n>> suacomp prefix needs to be told to the compiler. Without it, interix (at\n>> least the newer versions) are near unusable,...\n> \n> You are much more familiar with Interix than I am, and if you were the\n> only person who uses Interix with git, I would buy that argument\n> unconditionally.\n> \n> How has one built and used git before suacomp days? Are these users\n> extinct? Are there users who do not still use suacomp and for whatever\n> reason do not want to use it, but still want to use git?\n\nI did start the git porting when i ported Gentoo Prefix [1] to interix. I only ever tried to build it in there, and i actually don't think that there is any other build-case for interix (ATM). Maybe someday someone has the great idea of building/using git without Gentoo Prefix (good luck .. :)), but currently this is (AFAICT) not the case. In Gentoo Prefix in turn, suacomp is always there, on interix, and all versions are supported right now (interix 3.5 was not, but i did the work). Also, the compiler and linker are set up accordingly there.\n\nso, in order:\n 1) yes, i did in gentoo prefix, which now uses suacomp\n 2) yes, with the appearence of suacomp in gentoo prefix\n 3) if a user of gentoo prefix does not yet have suacomp,\n he/she will get upgraded automatically. i do not know\n of other users, and believe they don't exist.\n\n> \n> What I am getting at is that I have to come up with a description in the\n> release notes, and I cannot decide what the entry for this change should\n> say, and if I can stand behind that statement.\n> \n> Here is one version, based on my reading of what you said so far:\n> \n> * The build procedure for Interix now requires use of suacomp. Older\n> versions of Interix that are incompatible with suacomp are no longer\n> supported. The Makefile does not automatically tell \"the path to the\n> suacomp prefix\" to the compiler, so you would need to do that yourself.\n\nThe part with incompatible is no longer true. i tried building git on all interix versions, and it works fine. I feel, that if a user really installs plain interix, wan't git and isntalls suacomp himself, he/she will be power-user enough to manage and tell the build about some include/lib paths.\n\n> \n> Doesn't sound pretty, and I hesitate to stand behind such a statement.\n> Abandoning obsoleted versions of obscure platform nobody cares about is\n> fine, but at least we should make it clear who are being abandoned by\n> saying which version. Also \"needs to be told to the compiler\" part needs\n> some end-user explanation in Makefile (\"set HAVE_SUACOMP=/usr/lib/suacomp\n> when building on/for Interix\", or something).\n\nHm. suacomp is designed to be completely transparent to (nearly) everything involved in building a package. It should be part of the suacomp setup process to get it into the compiler/linker (by, for example, creating shell script wrappers around compiler/linker, much like colorgcc et. al.). If at all, i'd only set a HAVE_SUACOMP=YesPlease, and based on that, default some symbols to different values (exactly those that the 1/2 patch modifies).\n\n> \n> Here is another possible version (you would need to update your patch to\n> support both):\n> \n> * On Interix, it is preferrable to use suacomp to build git, but the old\n> way is still supported. Give HAVE_SUACOMP=/path/to/suacomp to Make (or\n> override it in your config.mak) when building git.\n\nThe \"old way\" was only supported on interix 6.0, as i found out. both interix 5.2 and 3.5 needed at least some additional workarounds, which are now gone with suacomp. I don't think that it would be worth the work (although i'd happily do it, if you want), to support an \"old way\" which has not a single advantage, and doesn't event work everywhere.\n\n> \n> That is more easily justifiable, but I cannot tell from this exchange with\n> you how important to keep supporting the old way is (or if it is even\n> possible).\n\nIt is possible, but as i said, i don't think it is worth it.\n\nHowever we proceed: thanks for contemplating about such an exotic platform. i really appreciate it!\nMarkus\n\n> \n"},{"id":"168978","messageId":"4DE33E55.6090505@gentoo.org","threadId":"27454","inReplyTo":"20110526163921.GD24931@elie","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Markus Duft","fromEmail":"mduft@gentoo.org","sentAt":"2011-05-30T06:51:01Z","receivedAt":"2011-05-30T06:51:01Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"On 05/26/11 18:39, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n> \n>> --- a/compat/fnmatch/fnmatch.c\n>> +++ b/compat/fnmatch/fnmatch.c\n>> @@ -127,6 +127,10 @@ extern char *getenv ();\n>> extern int errno;\n>> # endif\n>> +\n>> +# ifndef NULL\n>> +# define NULL 0\n>> +# endif\n> \n> Makes a lot of sense. This fits well with the style of the rest of\n> the file and other projects using glibc fnmatch could reuse the fix\n> even if targeting ancient platforms.\n\nI tested, and it works well on interix. Will you commit, or should i prepare a patch?\n\nThanks\nMarkus\n"},{"id":"170047","messageId":"4DF87C0D.3050108@gentoo.org","threadId":"27454","inReplyTo":"4DE33E55.6090505@gentoo.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Markus Duft","fromEmail":"mduft@gentoo.org","sentAt":"2011-06-15T09:31:57Z","receivedAt":"2011-06-15T09:31:57Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"On 05/30/11 08:51, Markus Duft wrote:\n> On 05/26/11 18:39, Jonathan Nieder wrote:\n>> Junio C Hamano wrote:\n>>\n>>> --- a/compat/fnmatch/fnmatch.c\n>>> +++ b/compat/fnmatch/fnmatch.c\n>>> @@ -127,6 +127,10 @@ extern char *getenv ();\n>>> extern int errno;\n>>> # endif\n>>> +\n>>> +# ifndef NULL\n>>> +# define NULL 0\n>>> +# endif\n>>\n>> Makes a lot of sense. This fits well with the style of the rest of\n>> the file and other projects using glibc fnmatch could reuse the fix\n>> even if targeting ancient platforms.\n> \n> I tested, and it works well on interix. Will you commit, or should i prepare a patch?\n\nping... is this one ok now?\n\nabout the other patch (1/2), i'm sorry that i messed up the thread a little... my last response was at [1]. could you take a look at it and tell me whether the patch is ok as is?\n\n[1] http://news.gmane.org/find-root.php?message_id=%3c4DDF4440.4040405%40gentoo.org%3e\n\nthanks,\nmarkus\n\n> \n> Thanks\n> Markus\n"},{"id":"170050","messageId":"20110615094842.GA16411@elie","threadId":"27454","inReplyTo":"4DF87C0D.3050108@gentoo.org","subject":"Re: [PATCH 2/2] Include unistd.h.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-15T09:48:42Z","receivedAt":"2011-06-15T09:48:42Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Markus,\n\nMarkus Duft wrote:\n>>> Junio C Hamano wrote:\n\n>>>> +++ b/compat/fnmatch/fnmatch.c\n>>>> @@ -127,6 +127,10 @@ extern char *getenv ();\n>>>> extern int errno;\n>>>> # endif\n>>>> +\n>>>> +# ifndef NULL\n>>>> +# define NULL 0\n>>>> +# endif\n[...]\n> ping... is this one ok now?\n\nHopefully yes. :) \"git log --grep=Interix origin/pu | git name-rev\n--stdin\" tells me that Junio applied it as v1.7.6-rc0~30\n(compat/fnmatch/fnmatch.c: give a fall-back definition for NULL,\n2011-05-26).\n\n> http://thread.gmane.org/gmane.comp.version-control.git/174407/focus=174600\n\nThat one I know less about, but I assume writing a hypothetical blurb\nfor the release notes (as part of the commit message) would help.\n\nThe main question I have is what the positive effect of removing the\nNO_SYS_POLL_H and NO_INTTYPES_H settings from the Makefile is --- does\nnew Gentoo not work with those settings? Is this a preparatory step\nbefore giving people time to upgrade and then removing support for\nthose settings from elsewhere in the codebase? Whatever the answer\nis, the log message would be nice to document it.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"170059","messageId":"1308137658-5509-1-git-send-email-mduft@gentoo.org","threadId":"27454","inReplyTo":"20110615094842.GA16411@elie","subject":"[PATCH] Update the Interix default build configuration.","fromName":"","fromEmail":"mduft@gentoo.org","sentAt":"2011-06-15T11:34:18Z","receivedAt":"2011-06-15T11:34:18Z","isPatch":true,"sender":{"key":"mduft@gentoo.org","avatar":null},"body":"Currently, on Interix, libsuacomp is required for building, see [1].\nSince suacomp provides poll() and inttypes.h for all interix versions,\nthe NO_*=YesPleas are removed.\n\nInterix versions 3 and 5 miss struct sockaddr_storage, so make git\navoid using it.\n\nSame for FNMATCH_CASEFOLD, which does not exist for Interix 3 and 5.\n\n[1] http://news.gmane.org/find-root.php?message_id=%3c4DDF4440.4040405%40gentoo.org%3e\n\nSigned-off-by: Markus Duft \n---\n Makefile | 6 ++++--\n 1 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex e40ac0c..2939e8d 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1124,8 +1124,6 @@ endif\n \tX = .exe\n endif\n ifeq ($(uname_S),Interix)\n-\tNO_SYS_POLL_H = YesPlease\n-\tNO_INTTYPES_H = YesPlease\n \tNO_INITGROUPS = YesPlease\n \tNO_IPV6 = YesPlease\n \tNO_MEMMEM = YesPlease\n@@ -1136,10 +1134,14 @@ ifeq ($(uname_S),Interix)\n \tifeq ($(uname_R),3.5)\n \t\tNO_INET_NTOP = YesPlease\n \t\tNO_INET_PTON = YesPlease\n+\t\tNO_SOCKADDR_STORAGE = YesPlease\n+\t\tNO_FNMATCH_CASEFOLD = YesPlease\n \tendif\n \tifeq ($(uname_R),5.2)\n \t\tNO_INET_NTOP = YesPlease\n \t\tNO_INET_PTON = YesPlease\n+\t\tNO_SOCKADDR_STORAGE = YesPlease\n+\t\tNO_FNMATCH_CASEFOLD = YesPlease\n \tendif\n endif\n ifneq (,$(findstring MINGW,$(uname_S)))\n-- \n1.7.3.4\n"}]}