After running make distcheck
I get the message that I have successfully built the package and is ready for distribution. If I untar the tar.gz
with tar -zxvf hello-0.2.tar.gz
it successfully extracts all of its contents. However, when I try to extract them in different machines I get:
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
The weird thing is that it was working before.
On the machine I'm trying to build the package, I've updated my automake 1.10.1, autoconf 2开发者_StackOverflow.61, and tar 1.20 to automake 1.11.1, autoconf 2.65, and tar 1.23
and still the same issue.
Any ideas what could be the problem?
The problem is not on the build machine; the problem is on the target machines.
Not all versions of tar
automatically recognize the decompression to apply to a compressed tar
file. Given that gunzip
followed by tar
does work, then the tar
on your target machine is one such. The versions of tar
on the mainstream Unix systems (AIX, HP-UX, Solaris) do not recognize compressed tar files automatically. Those on Linux and MacOS X do.
Note that you can use:
gzip -dc hello-0.2.tar.gz | tar -xf -
to avoid creating the intermediate uncompressed file.
Actually this could happen when the server you download from applies another round of GZip and the client you used to download the file doesn't read/respect the HTTP Content-Encoding
header and stores the HTTP payload as it was on the wire.
Although the file appears to have only the extension .tar.gz
it is in fact .tar.gz.gz
. after you run the gunzip
once the file gets the extension .tar
only but still this time running the tar command tar xf hello-0.2.tar
recognizes the GZip format and implicitly runs the file through gunzip one more time before extracting.
You can check this by running head hello-02.tar.gz
and head hello-02.tar
. GZip is a very binary format, whereas tar is quite human readable. If the .tar file appears "too binary" you have a doubly encoded file on your hands.
精彩评论