# [PATCH] Build on Debian GNU/Hurd 7 messages from 2006-09-15 to 2006-09-22. Participants: Gerrit Pape, Martin Waitz, Junio C Hamano, Ramsay Jones, Linus Torvalds. Thread: https://gitlist.dev/t/5570 ## Gerrit Pape, 2006-09-15 12:58 Subject: [PATCH] Build on Debian GNU/Hurd Message-ID: <20060915125846.10469.qmail@ccc765dd61a02d.315fe32.mid.smarden.org> URL: https://gitlist.dev/e/20060915125846.10469.qmail%40ccc765dd61a02d.315fe32.mid.smarden.org ``` Patch from Cyril Brulebois to make the build process detect and support the Debian GNU/Hurd architecture, see http://bugs.debian.org/379841 Signed-off-by: Gerrit Pape --- Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 7b3114f..6e36eff 100644 --- a/Makefile +++ b/Makefile @@ -383,6 +383,11 @@ ifeq ($(uname_S),NetBSD) ALL_CFLAGS += -I/usr/pkg/include ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib endif +ifeq ($(uname_S),GNU) + # GNU stands for GNU/Hurd + NO_STRLCPY = YesPlease + ALL_CFLAGS += -DPATH_MAX=4096 +endif ifeq ($(uname_S),AIX) NO_STRCASESTR=YesPlease NO_STRLCPY = YesPlease -- 1.4.2.1 ``` ## Martin Waitz, 2006-09-15 15:47 Subject: Re: [PATCH] Build on Debian GNU/Hurd Message-ID: <20060915154742.GT17042@admingilde.org> URL: https://gitlist.dev/e/20060915154742.GT17042%40admingilde.org In-Reply-To: <20060915125846.10469.qmail@ccc765dd61a02d.315fe32.mid.smarden.org> ``` hoi :) On Fri, Sep 15, 2006 at 12:58:46PM +0000, Gerrit Pape wrote: > +ifeq ($(uname_S),GNU) > + # GNU stands for GNU/Hurd > + NO_STRLCPY = YesPlease > + ALL_CFLAGS += -DPATH_MAX=4096 > +endif I guess this arbitrary limit will upset all the Hurd enthusiasts... ;-) -- Martin Waitz ``` ## Junio C Hamano, 2006-09-16 05:35 Subject: Re: [PATCH] Build on Debian GNU/Hurd Message-ID: <7vr6yce5ky.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr6yce5ky.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060915125846.10469.qmail@ccc765dd61a02d.315fe32.mid.smarden.org> ``` Gerrit Pape writes: > Patch from Cyril Brulebois to make the build process detect and support the > Debian GNU/Hurd architecture, see > http://bugs.debian.org/379841 > > Signed-off-by: Gerrit Pape > > +ifeq ($(uname_S),GNU) > + # GNU stands for GNU/Hurd > + NO_STRLCPY = YesPlease > + ALL_CFLAGS += -DPATH_MAX=4096 > +endif Two questions come to mind. (1) Does GNU stand for GNU/Hurd and nobody else? (2) Does everybody else have PATH_MAX? Adding NO_STRLCPY I do not have much problems with, but something like the attached may be cleaner to deal with PATH_MAX; of course now there is an issue of what the appropriate value for that symbol should be. Would including git-compat-util.h in builtin.h break somebody? -- >8 -- Define fallback PATH_MAX on systems that do not define one in Notably GNU/Hurd, as reported by Gerrit Pape. Signed-off-by: Junio C Hamano --- diff --git a/git-compat-util.h b/git-compat-util.h index 552b8ec..0272d04 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -26,6 +26,13 @@ #include #include #include +/* On most systems would have given us this, but + * not on some systems (e.g. GNU/Hurd). + */ +#ifndef PATH_MAX +#define PATH_MAX 4096 +#endif + #ifdef __GNUC__ #define NORETURN __attribute__((__noreturn__)) #else diff --git a/builtin.h b/builtin.h index 34ed7b9..1d41f83 100644 --- a/builtin.h +++ b/builtin.h @@ -1,8 +1,7 @@ #ifndef BUILTIN_H #define BUILTIN_H -#include -#include +#include "git-compat-util.h" extern const char git_version_string[]; extern const char git_usage_string[]; ``` ## Gerrit Pape, 2006-09-19 17:03 Subject: Re: [PATCH] Build on Debian GNU/Hurd Message-ID: <20060919170335.28054.qmail@14e0e1fe2bc371.315fe32.mid.smarden.org> URL: https://gitlist.dev/e/20060919170335.28054.qmail%4014e0e1fe2bc371.315fe32.mid.smarden.org In-Reply-To: <7vr6yce5ky.fsf@assigned-by-dhcp.cox.net> ``` On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote: > Gerrit Pape writes: > > Patch from Cyril Brulebois to make the build process detect and support the > > Debian GNU/Hurd architecture, see > > http://bugs.debian.org/379841 > > > > Signed-off-by: Gerrit Pape > > > > +ifeq ($(uname_S),GNU) > > + # GNU stands for GNU/Hurd > > + NO_STRLCPY = YesPlease > > + ALL_CFLAGS += -DPATH_MAX=4096 > > +endif > > Two questions come to mind. (1) Does GNU stand for GNU/Hurd and > nobody else? (2) Does everybody else have PATH_MAX? I'm not that familiar with the Hurd, but (1) seems to be so according to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly git$ grep -B7 -A3 PATH_MAX Makefile ifeq ($(uname_S),IRIX64) NO_IPV6=YesPlease NO_SETENV=YesPlease NO_STRCASESTR=YesPlease NO_STRLCPY = YesPlease NO_SOCKADDR_STORAGE=YesPlease SHELL_PATH=/usr/gnu/bin/bash ALL_CFLAGS += -DPATH_MAX=1024 # for now, build 32-bit version ALL_LDFLAGS += -L/usr/lib32 endif that's where I got it from. > Adding NO_STRLCPY I do not have much problems with, but > something like the attached may be cleaner to deal with PATH_MAX; > of course now there is an issue of what the appropriate value > for that symbol should be. It's been so before it seems, I'm not sure why it changed. http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot expect PATH_MAX to be defined on a POSIX system, so defining it conditionally IMHO is the right thing. git$ PAGER=cat git log -p 579d1fb..8e76483 commit 8e76483ce0ce256b01345abc4ca97b1f94aed354 Author: Ramsay Allan Jones Date: Sun Jul 30 17:00:40 2006 +0100 Fix header breakage due to redefining PATH_MAX. The header builtin.h was, incorrectly, redefining PATH_MAX which causes a header order dependency in builtin-write-tree.c. The fix is to simply include directly to obtain the correct definition of PATH_MAX. Signed-off-by: Ramsay Allan Jones Signed-off-by: Junio C Hamano diff --git a/builtin.h b/builtin.h index 1c8637a..88c4d84 100644 --- a/builtin.h +++ b/builtin.h @@ -2,10 +2,7 @@ #ifndef BUILTIN_H #define BUILTIN_H #include - -#ifndef PATH_MAX -# define PATH_MAX 4096 -#endif +#include extern const char git_version_string[]; HTH, Gerrit. ``` ## Ramsay Jones, 2006-09-21 17:37 Subject: RE: [PATCH] Build on Debian GNU/Hurd Message-ID: <000001c6dda4$ad0b1ec0$c47eedc1@ramsay1.demon.co.uk> URL: https://gitlist.dev/e/000001c6dda4%24ad0b1ec0%24c47eedc1%40ramsay1.demon.co.uk In-Reply-To: <20060919170335.28054.qmail@14e0e1fe2bc371.315fe32.mid.smarden.org> ``` On Tues Sept 19, 2006 at 18:04, Gerrit Pape wrote: > On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote: > > Gerrit Pape writes: > > > Patch from Cyril Brulebois to make the build process detect > and support the > > > Debian GNU/Hurd architecture, see > > > http://bugs.debian.org/379841 > > > > > > Signed-off-by: Gerrit Pape > > > > > > +ifeq ($(uname_S),GNU) > > > + # GNU stands for GNU/Hurd > > > + NO_STRLCPY = YesPlease > > > + ALL_CFLAGS += -DPATH_MAX=4096 > > > +endif > > > > Two questions come to mind. (1) Does GNU stand for GNU/Hurd and > > nobody else? (2) Does everybody else have PATH_MAX? > > I'm not that familiar with the Hurd, but (1) seems to be so according > to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU > or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly > > git$ grep -B7 -A3 PATH_MAX Makefile > ifeq ($(uname_S),IRIX64) > NO_IPV6=YesPlease > NO_SETENV=YesPlease > NO_STRCASESTR=YesPlease > NO_STRLCPY = YesPlease > NO_SOCKADDR_STORAGE=YesPlease > SHELL_PATH=/usr/gnu/bin/bash > ALL_CFLAGS += -DPATH_MAX=1024 > # for now, build 32-bit version > ALL_LDFLAGS += -L/usr/lib32 > endif > > that's where I got it from. > > > Adding NO_STRLCPY I do not have much problems with, but > > something like the attached may be cleaner to deal with PATH_MAX; > > of course now there is an issue of what the appropriate value > > for that symbol should be. > > It's been so before it seems, I'm not sure why it changed. Because without the change (below), git would not compile for me ;-) Indeed it would not compile for any system that: 1) defines PATH_MAX in limits.h AND 2) conditionally defines PATH_MAX to a different value. (Actually, it does not have to be a different value, just a different token sequence, including the presence/absence of whitespace/comments) Note that other systems use a different "PATH_MAX value", (a value of 1024 is common), and in particular, earlier version of linux use a value of 4095. > http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot > expect PATH_MAX to be defined on a POSIX system, Correct. Although PATH_MAX is a POSIX symbol, it is not required to be defined; it *may* be defined in limits.h and, if so, must have a value of at least 256. The symbol _PC_PATH_MAX *may* also be defined and, if so, may be used in a call to pathconf() to *maybe* determine a "PATH_MAX value" at runtime; it can return a value, indicate no limit, or an "indeterminate" limit. ... so defining it > conditionally IMHO is the right thing. IMHO, setting the value in the Makefile, for systems that don't define PATH_MAX, is a much better solution. In fact, that is what I thought was already being done. All the best, Ramsay > > git$ PAGER=cat git log -p 579d1fb..8e76483 > commit 8e76483ce0ce256b01345abc4ca97b1f94aed354 > Author: Ramsay Allan Jones > Date: Sun Jul 30 17:00:40 2006 +0100 > > Fix header breakage due to redefining PATH_MAX. > > The header builtin.h was, incorrectly, redefining PATH_MAX which > causes a header order dependency in builtin-write-tree.c. The fix > is to simply include directly to obtain the correct > definition of PATH_MAX. > > Signed-off-by: Ramsay Allan Jones > Signed-off-by: Junio C Hamano > > diff --git a/builtin.h b/builtin.h > index 1c8637a..88c4d84 100644 > --- a/builtin.h > +++ b/builtin.h > @@ -2,10 +2,7 @@ #ifndef BUILTIN_H > #define BUILTIN_H > > #include > - > -#ifndef PATH_MAX > -# define PATH_MAX 4096 > -#endif > +#include > > extern const char git_version_string[]; > ``` ## Linus Torvalds, 2006-09-21 17:53 Subject: RE: [PATCH] Build on Debian GNU/Hurd Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0609211050390.4388%40g5.osdl.org In-Reply-To: <000001c6dda4$ad0b1ec0$c47eedc1@ramsay1.demon.co.uk> ``` On Thu, 21 Sep 2006, Ramsay Jones wrote: > > IMHO, setting the value in the Makefile, for systems that don't define > PATH_MAX, is a much better solution. In fact, that is what I thought was > already being done. Well, considering that we _can_ test defines, why not just do it automatically. In other words, instead of this patch: > > - > > -#ifndef PATH_MAX > > -# define PATH_MAX 4096 > > -#endif > > +#include Just make the code read #include /* * Insane systems don't have a fixed PATH_MAX, it's POSIX * compliant but not worth worrying about, so if we didn't * get PATH_MAX from , just make up our own */ #ifndef PATH_MAX # define PATH_MAX 4096 #endif and after that we can just ignore the issue forever more. The thing is, it's not like we even really _care_ what PATH_MAX is all that deeply. We just want to get some random value that is reasonable. Linus ``` ## Ramsay Jones, 2006-09-22 17:22 Subject: RE: [PATCH] Build on Debian GNU/Hurd Message-ID: <000001c6de6b$a9994920$c47eedc1@ramsay1.demon.co.uk> URL: https://gitlist.dev/e/000001c6de6b%24a9994920%24c47eedc1%40ramsay1.demon.co.uk In-Reply-To: ``` On Thurs Sept 21 at 18:54, Linus Torvalds wrote: > On Thu, 21 Sep 2006, Ramsay Jones wrote: > > > > IMHO, setting the value in the Makefile, for systems that don't define > > PATH_MAX, is a much better solution. In fact, that is what I thought was > > already being done. > > Well, considering that we _can_ test defines, why not just do it > automatically. > > In other words, instead of this patch: > > > > - > > > -#ifndef PATH_MAX > > > -# define PATH_MAX 4096 > > > -#endif > > > +#include > > Just make the code read > > #include > > /* > * Insane systems don't have a fixed PATH_MAX, it's POSIX > * compliant but not worth worrying about, so if we didn't > * get PATH_MAX from , just make up our own > */ > #ifndef PATH_MAX > # define PATH_MAX 4096 > #endif > > and after that we can just ignore the issue forever more. Yes, that would certainly be a solution. (Of course, setting the value in the Makefile would still be a better solution ;-) However, ... > > The thing is, it's not like we even really _care_ what PATH_MAX is all > that deeply. We just want to get some random value that is reasonable. > > Linus > ... given the above, a better solution is: don't use PATH_MAX. Simply #define a new symbol in a suitable git header file and globally replace uses of PATH_MAX with the new symbol. Job done. All the best, Ramsay ```