# git-1.4.0 make problems 5 messages from 2006-06-17 to 2006-06-17. Participants: Michael Somos, Rene Scharfe, Junio C Hamano. Thread: https://gitlist.dev/t/4536 ## Michael Somos, 2006-06-17 02:18 Subject: git-1.4.0 make problems Message-ID: <200606170218.k5H2I0o0003192@grail.cba.csuohio.edu> URL: https://gitlist.dev/e/200606170218.k5H2I0o0003192%40grail.cba.csuohio.edu ``` I downloaded the git-1.4.0.tar.bz2 recently and encountered a few problems. 1) The untar process creates a stray file "pax_global_header". I am using GNU tar v1.13.22 and I get this message : ====================================================================== > tar jxf ~/u/source/git-1.4.0.tar.bz2 tar: pax_global_header: Unknown file type 'g', extracted as normal file ====================================================================== 2) The make install process ignores the "prefix=..." argument. I have to comment out one line for this : ====================================================================== > diff Makefile git-1.4.0/ 94c94 < #prefix = $(HOME) --- > prefix = $(HOME) ====================================================================== 3) The make has a problem with "expat" include and libararies. I have to add more lines to the Makefile to handle this like some of the other include and libraries : ====================================================================== 351,358c351 < endif < < ifndef NO_EXPAT < ifdef EXPATDIR < # This is still problematic -- gcc does not always want -R. < ALL_CFLAGS += -I$(EXPATDIR)/include < EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat < else --- > ifndef NO_EXPAT 360c353 < endif --- > endif ====================================================================== Other than that, it installed okay. I will have to read the docs and use it to see how it goes otherwise. ``` ## Rene Scharfe, 2006-06-17 06:58 Subject: Re: git-1.4.0 make problems Message-ID: <4493A810.6010706@lsrfire.ath.cx> URL: https://gitlist.dev/e/4493A810.6010706%40lsrfire.ath.cx In-Reply-To: <200606170218.k5H2I0o0003192@grail.cba.csuohio.edu> ``` | I downloaded the git-1.4.0.tar.bz2 recently and encountered a few | problems. | | 1) The untar process creates a stray file "pax_global_header". | I am using GNU tar v1.13.22 and I get this message : | | ====================================================================== | > tar jxf ~/u/source/git-1.4.0.tar.bz2 | tar: pax_global_header: Unknown file type 'g', extracted as normal | file | ====================================================================== You can ignore or delete that file. It is a pax extended global header, containing the git commit ID as a comment. GNU tar started supporting pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22 was released on 2001-08-29, by the way. May I ask what operating system and version you are using? | 2) The make install process ignores the "prefix=..." argument. I have | to comment out one line for this : | | ====================================================================== | > diff Makefile git-1.4.0/ | 94c94 | < #prefix = $(HOME) | --- | > prefix = $(HOME) | ====================================================================== It took me a while to realize that your diffs are reversed. It's too early for me, I think I'll go to bed again. :) Anyway, prefix handling is currently being worked on. Yakov Lerner sent a patch which seems to make make do what you need. | 3) The make has a problem with "expat" include and libararies. | I have to add more lines to the Makefile to handle this like some | of the other include and libraries : | | ====================================================================== | 351,358c351 | < endif | < | < ifndef NO_EXPAT | < ifdef EXPATDIR | < # This is still problematic -- gcc does not always want -R. | < ALL_CFLAGS += -I$(EXPATDIR)/include | < EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat | | < else | --- | > ifndef NO_EXPAT | 360c353 | < endif | --- | > endif | ====================================================================== Looks sensible, except for the formatting. | Other than that, it installed okay. I will have to read the docs and | use it to see how it goes otherwise. A good first exercise would be to fetch the git repository, edit Makefile and commit your change, and then send a patch to this list -- all using git (except the editing part). :-) Care to try that? Please let us know of any difficulties you may encounter. Thanks, René ``` ## Junio C Hamano, 2006-06-17 20:56 Subject: Re: git-1.4.0 make problems Message-ID: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqsra4d2.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <4493A810.6010706@lsrfire.ath.cx> ``` Rene Scharfe writes: > | 1) The untar process creates a stray file "pax_global_header". > | I am using GNU tar v1.13.22 and I get this message : > | > | ====================================================================== > | > tar jxf ~/u/source/git-1.4.0.tar.bz2 > | tar: pax_global_header: Unknown file type 'g', extracted as normal > | file > | ====================================================================== > > You can ignore or delete that file. It is a pax extended global header, > containing the git commit ID as a comment. GNU tar started supporting > pax headers with version 1.13.93 (released 2004-02-23). Version 1.13.22 > was released on 2001-08-29, by the way. May I ask what operating system > and version you are using? I've been using (in my non-git related project aka day-job) git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar to avoid this. Although all of my target machines have gtar that are recent enough so I do not need it, but when the tarball has version string in its name, there is not much point having the pax header to identify the contents (where the pax header shines is when the result does not have the version string in its name). This might be a sensible thing to do for our dist target as well. The product of our dist target is for people who build from the source to bootstrap themselves (if they have git, then fetching the source using git is preferred anyway), as opposed to using pre-built binaries, so being as friendly as we can to different implementations of tar is a good thing. ``` ## Rene Scharfe, 2006-06-17 21:55 Subject: Re: git-1.4.0 make problems Message-ID: <44947A43.7070909@lsrfire.ath.cx> URL: https://gitlist.dev/e/44947A43.7070909%40lsrfire.ath.cx In-Reply-To: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano schrieb: > I've been using (in my non-git related project aka day-job) > > git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar > > to avoid this. Although all of my target machines have gtar that are > recent enough so I do not need it, but when the tarball has version > string in its name, there is not much point having the pax header to > identify the contents (where the pax header shines is when the result > does not have the version string in its name). > > This might be a sensible thing to do for our dist target as well. > The product of our dist target is for people who build from the > source to bootstrap themselves (if they have git, then fetching the > source using git is preferred anyway), as opposed to using pre-built > binaries, so being as friendly as we can to different implementations > of tar is a good thing. Hrm. Is the header really that unfriendly? With a non-POSIX tar you get an extra file and a nice, if somewhat cryptic, reminder to upgrade your archiver. ;-) Seriously, this is way below my annoyance-radar, but I'm obviously biased. What do you think about the following patch for starters? It adds an example to the git-tar-tree documentation showing your "tree trick" and corrects two formatting buglets. Signed-off-by: Rene Scharfe diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt index 831537b..c93a8fe 100644 --- a/Documentation/git-tar-tree.txt +++ b/Documentation/git-tar-tree.txt @@ -45,11 +45,16 @@ git tar-tree HEAD | (cd /var/tmp/ && mkd latest commit on the current branch, and extracts it in `/var/tmp/junk` directory. -git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz +git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz:: Create a tarball for v2.6.17 release. -git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar +git tar-tree v2.6.17{caret}\{tree\} linux-2.6.17 | gzip >linux-2.6.17.tar.gz:: + + Create a tarball for v2.6.17 release, but without a + global extended pax header. + +git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar:: Get a tarball v0.99 from example.com. ``` ## Junio C Hamano, 2006-06-17 22:40 Subject: Re: git-1.4.0 make problems Message-ID: <7vac8b76ey.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vac8b76ey.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <44947A43.7070909@lsrfire.ath.cx> ``` Rene Scharfe writes: > Hrm. Is the header really that unfriendly? With a non-POSIX tar you > get an extra file and a nice, if somewhat cryptic, reminder to upgrade > your archiver. ;-) Seriously, this is way below my annoyance-radar, > but I'm obviously biased. I do not mind tar-tree producing the header by default and having to override it with ^{tree} -- actually I think it is a good default. I think that particular use in our Makefile, however, is not necessary. > What do you think about the following patch for starters? Documentation updates are always welcome, and I think this is a good change. Thanks. ```