From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18203 invoked by alias); 30 Jul 2004 15:16:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 18193 invoked by uid 48); 30 Jul 2004 15:16:34 -0000 Date: Fri, 30 Jul 2004 15:16:00 -0000 From: "scott dot bailey at eds dot com" To: gcc-bugs@gcc.gnu.org Message-ID: <20040730151633.16836.scott.bailey@eds.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug bootstrap/16836] New: gcc-3.4.1.tar.gz requires GNU tar to unpack X-Bugzilla-Reason: CC X-SW-Source: 2004-07/txt/msg03573.txt.bz2 List-Id: It's a stretch to call this a bootstrap issue, but what else do you say? :-) On Tru64 5.1B, using the native tar utility, I see this: # gunzip -c gcc-3.4.1.tar.gz | tar xf - tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype tar: ././@LongLink : Unknown filetype I have never seen this happen with any tarball before. I worked around the problem by downloading and building GNU tar, which was then happy to unpack things for me. But I found it rather annoying... Could you either "squish" things enough to avoid this issue, or add a notice to the web site mentioning this requirement? Thanks, Scott -- Summary: gcc-3.4.1.tar.gz requires GNU tar to unpack Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scott dot bailey at eds dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alphaev56-dec-osf5.1 GCC host triplet: alphaev56-dec-osf5.1 GCC target triplet: alphaev56-dec-osf5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16836