web-dev-qa-db-ja.com

Autotools-tarこれはtarアーカイブのようには見えません

make distcheckを実行した後、パッケージが正常にビルドされ、配布の準備ができたというメッセージが表示されます。 tar.gzをtar -zxvf hello-0.2.tar.gzで解凍すると、すべてのコンテンツが正常に抽出されます。ただし、別のマシンでそれらを抽出しようとすると、次のようになります。

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

奇妙なことは、それが以前は機能していたということです。

パッケージをビルドしようとしているマシンで、automake 1.10.1, autoconf 2.61, and tar 1.20 to automake 1.11.1, autoconf 2.65, and tar 1.23を更新しましたが、それでも同じ問題が発生します。

問題となる可能性のあるアイデアはありますか？

tarautotoolsautoconfautomake
16
denim69

問題はビルドマシンにはありません。問題はターゲットマシンにあります。

tarのすべてのバージョンが、圧縮されたtarファイルに適用する解凍を自動的に認識するわけではありません。 gunzipの後にtarが続くことを考えると、ターゲットマシンのtarはそのようなものの1つです。メインストリームのUnixシステム（AIX、HP-UX、Solaris）のtarのバージョンは、圧縮されたtarファイルを自動的に認識しません。 LinuxとMacOSXのものはそうです。

次のものを使用できることに注意してください。

gzip -dc hello-0.2.tar.gz | tar -xf -

中間の非圧縮ファイルの作成を回避するため。

14
Jonathan Leffler

実際、これは、ダウンロード元のサーバーがGZipの別のラウンドを適用し、ファイルのダウンロードに使用したクライアントがHTTP Content-Encodingヘッダーを読み取らない/尊重せず、HTTPペイロードをネットワーク上に保存している場合に発生する可能性があります。

ファイルの拡張子は.tar.gzのみのように見えますが、実際には.tar.gz.gzです。 gunzipを実行した後、ファイルの拡張子は.tarのみですが、今回はtarコマンドを実行するとtar xf hello-0.2.tarがGZip形式を認識し、ファイルをもう一度gunzipで暗黙的に実行します。抽出します。

これは、head hello-02.tar.gzおよびhead hello-02.tarを実行することで確認できます。 GZipは非常にバイナリ形式ですが、tarは人間が読める形式です。 .tarファイルが「バイナリすぎる」と表示される場合は、二重にエンコードされたファイルが手元にあります。

4
Gesh