Error building installing on Redhat Linux Server release 5.3 (Tikanga)

Error building installing on Redhat Linux Server release 5.3 (Tikanga)

[Michael Cox]

I downloaded the latest tarball (git-1.7.0.2), configured it, and
make'ed it.  When I did a "make install", the build seemed to work and
most of the install, but I got an error when the installation tried to
use gtar:

make -C templates DESTDIR='' install
make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
(cd blt && gtar cf - .) | \
        (cd '/home/e477610/exptool/share/git-core/templates' && umask
022 && gtar xof -)
gtar: This does not look like a tar archive
gtar: Skipping to next header
gtar: Archive contains obsolescent base-64 headers
gtar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
make[1]: Leaving directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
make: *** [install] Error 2

When I try to run "git clone
http://www.kernel.org/pub/scm/git/git.git", I get the following error:

$  git clone http://www.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /users/e477610/exptool/src/git/.git/
fatal: Unable to find remote helper for 'http'

I assume it's because I didn't finish the install properly.  Any ideas
why the install of the build failed and what I could do to make it
complete?

Michael

Re: Error building installing on Redhat Linux Server release 5.3 (Tikanga)

[Michael Cox]

That fixed the build problem.  Thank you!

But when I tried to run git after the successful build:

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

I still get the error message "fatal: Unable to find remote helper for 'http'"

Michael

P.S. I have to use http since I'm behind a firewall.


On Fri, Mar 19, 2010 at 4:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Cox <mhcox@bluezoosoftware.com> writes:
>
>> I downloaded the latest tarball (git-1.7.0.2), configured it, and
>> make'ed it.  When I did a "make install", the build seemed to work and
>> most of the install, but I got an error when the installation tried to
>> use gtar:
>>
>> make -C templates DESTDIR='' install
>> make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
>> install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
>> (cd blt && gtar cf - .) | \
>>         (cd '/home/e477610/exptool/share/git-core/templates' && umask
>> 022 && gtar xof -)
>> gtar: This does not look like a tar archive
>
> A shot in the dark:
>
>        $ unset CDPATH
>
> Also remove anything that sets CDPATH from your .bashrc if you are making
> it available to your non-interactive shell processes.
>

Re: Error building installing on Redhat Linux Server release 5.3 (Tikanga)

[Michael Cox]

I noticed the following messages in the config.log

/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libcurl.so: undefined reference to
 `tld_strerror'
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libcurl.so: undefined reference to
 `idna_strerror'

Could that be the source of my problem?

Michael



On Fri, Mar 19, 2010 at 4:25 PM, Michael Cox <mhcox@bluezoosoftware.com> wrote:
> That fixed the build problem.  Thank you!
>
> But when I tried to run git after the successful build:
>
>    git clone http://www.kernel.org/pub/scm/git/git.git
>
> I still get the error message "fatal: Unable to find remote helper for 'http'"
>
> Michael
>
> P.S. I have to use http since I'm behind a firewall.
>
>
> On Fri, Mar 19, 2010 at 4:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Michael Cox <mhcox@bluezoosoftware.com> writes:
>>
>>> I downloaded the latest tarball (git-1.7.0.2), configured it, and
>>> make'ed it.  When I did a "make install", the build seemed to work and
>>> most of the install, but I got an error when the installation tried to
>>> use gtar:
>>>
>>> make -C templates DESTDIR='' install
>>> make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
>>> install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
>>> (cd blt && gtar cf - .) | \
>>>         (cd '/home/e477610/exptool/share/git-core/templates' && umask
>>> 022 && gtar xof -)
>>> gtar: This does not look like a tar archive
>>
>> A shot in the dark:
>>
>>        $ unset CDPATH
>>
>> Also remove anything that sets CDPATH from your .bashrc if you are making
>> it available to your non-interactive shell processes.
>>
>

[PATCH] Makefile: Fix CDPATH problem

[Jonathan Nieder]

CDPATH takes scripts to unexpected places.  For example, with a CDPATH
including a blt directory:

 make -C templates DESTDIR='' install
 make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
 install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
 (cd blt && gtar cf - .) | \
	(cd '/home/e477610/exptool/share/git-core/templates' && umask 022 && gtar xof -)
 gtar: This does not look like a tar archive

The CDPATH mechanism does not implicitly add "." at the beginning of
CDPATH, which is the most irritating part.

Most git scripts already protect against use of CDPATH through
git-sh-setup, but the Makefile doesn’t.

Reported-by: Michael Cox <mhcox@bluezoosoftware.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I wouldn’t have guessed that.  Thanks, Junio.

Michael Cox wrote:
> That fixed the build problem.  Thank you!

Here’s a patch to prevent it from happening again.

 Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 4387d42..c1f4161 100644
--- a/Makefile
+++ b/Makefile
@@ -317,6 +317,12 @@ SCRIPT_PYTHON =
 SCRIPT_SH =
 TEST_PROGRAMS =
 
+# Having this variable in your environment would break scripts because
+# you would cause "cd" to be taken to unexpected places.  If you
+# like CDPATH, define it for your interactive shell sessions without
+# exporting it.
+unexport CDPATH
+
 SCRIPT_SH += git-am.sh
 SCRIPT_SH += git-bisect.sh
 SCRIPT_SH += git-difftool--helper.sh
-- 
1.7.0.2.468.g1637

Re: [PATCH] Makefile: Fix CDPATH problem

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> CDPATH takes scripts to unexpected places.  For example, with a CDPATH
> including a blt directory:
>
>  make -C templates DESTDIR='' install
>  make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
>  install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
>  (cd blt && gtar cf - .) | \
> 	(cd '/home/e477610/exptool/share/git-core/templates' && umask 022 && gtar xof -)
>  gtar: This does not look like a tar archive
>
> The CDPATH mechanism does not implicitly add "." at the beginning of
> CDPATH, which is the most irritating part.
>
> Most git scripts already protect against use of CDPATH through
> git-sh-setup, but the Makefile doesn’t.

Eh, the rationale and the in-code comment need to be fixed.  The issue is
not "taking us to random places", but "reporting the name of the random
place in its standard output".

But other than that, this is something we have seen on the list a few
times, and I think it is about time to do this.

Thanks.

[PATCH v2] Makefile: Fix CDPATH problem

[Jonathan Nieder]

If CDPATH is set, "cd" prints its destination to stdout, causing
the common (cd a && tar cf - .) | (cd b && tar xf -) idiom to fail.
For example:

 make -C templates DESTDIR='' install
 make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates'
 install -d -m 755 '/home/e477610/exptool/share/git-core/templates'
 (cd blt && gtar cf - .) | \
	(cd '/home/e477610/exptool/share/git-core/templates' && umask 022 && gtar xof -)
 gtar: This does not look like a tar archive

Most git scripts already protect against use of CDPATH through
git-sh-setup, but the Makefile doesn’t.

Reported-by: Michael Cox <mhcox@bluezoosoftware.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
> Eh, the rationale and the in-code comment need to be fixed.  The issue is
> not "taking us to random places", but "reporting the name of the random
> place in its standard output".

That makes more sense.  Thanks.

> But other than that, this is something we have seen on the list a few
> times, and I think it is about time to do this.

Here’s an updated patch.

 Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 4387d42..98372eb 100644
--- a/Makefile
+++ b/Makefile
@@ -317,6 +317,12 @@ SCRIPT_PYTHON =
 SCRIPT_SH =
 TEST_PROGRAMS =
 
+# Having this variable in your environment would break pipelines because
+# you cause "cd" to echo its destination to stdout.  It can also take
+# scripts to unexpected places.  If you like CDPATH, define it for your
+# interactive shell sessions without exporting it.
+unexport CDPATH
+
 SCRIPT_SH += git-am.sh
 SCRIPT_SH += git-bisect.sh
 SCRIPT_SH += git-difftool--helper.sh
-- 
1.7.0

Re: Error building installing on Redhat Linux Server release 5.3 (Tikanga)

[Jonathan Nieder]

Michael Cox wrote:

> (cd blt && gtar cf - .) | \
>         (cd '/home/e477610/exptool/share/git-core/templates' && umask 022 && gtar xof -)
> gtar: This does not look like a tar archive
> gtar: Skipping to next header
> gtar: Archive contains obsolescent base-64 headers
> gtar: Error exit delayed from previous errors
> make[1]: *** [install] Error 2

Your tar command seems to be seriously broken: it is producing output
that it cannot consume.

What is the output of “gtar --version”?  Does this problem still occur if
you try again?  If you run the command above by hand, does it produce
the same result?

I checked https://bugzilla.redhat.com/ for known problems but did not
find anything similar.  If this problem proves reproducible, I would
suggest reporting it with them.

In the mean time, you can use git without installing it by adding
/home/e477610/exptool/share/git-core/bin-wrappers to your $PATH. :)

Hope that helps,
Jonathan

Re: Error building installing on Redhat Linux Server release 5.3 (Tikanga)

[Jonathan Nieder]

Jonathan Nieder wrote:

> In the mean time, you can use git without installing it by adding
> /home/e477610/exptool/share/git-core/bin-wrappers to your $PATH. :)

Or rather $(pwd)/bin-wrappers, where $(pwd) is the directory git was
built in.  I read your message a little too quickly, sorry.