From owner-freebsd-amd64@FreeBSD.ORG Thu Aug 12 01:04:15 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E739416A4CE; Thu, 12 Aug 2004 01:04:15 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5366343D2F; Thu, 12 Aug 2004 01:04:15 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id EE3FA530D; Thu, 12 Aug 2004 03:04:13 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id C391C530C; Thu, 12 Aug 2004 03:04:05 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id B9741B872; Thu, 12 Aug 2004 03:04:04 +0200 (CEST) To: Tilman Linneweh References: <20040807190400.GB24054@arved.at> <20040811074556.GD24054@arved.at> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 12 Aug 2004 03:04:04 +0200 In-Reply-To: <20040811074556.GD24054@arved.at> (Tilman Linneweh's message of "Wed, 11 Aug 2004 09:45:56 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: amd64@FreeBSD.org Subject: Re: fetch calculates size wrong X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 01:04:16 -0000 Tilman Linneweh writes: > Hm, the code in libfetch hasn't been touched for a while, and I didn't no= tice > any problem with fetch in June.=20 I just heard from kuriyama@ who had the same problem and managed to track it down. There's code in fetch.c that incorrectly expects struct stat to be unmodified when stat(2) fails, and gcc 3.4 just happens to break that assumption on amd64. I'll commit a patch shortly. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no