Date: Wed, 7 Jul 2004 13:45:01 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Marius Strobl <marius@alchemy.franken.de> Cc: current@freebsd.org Subject: Re: Query on status of cross-builds Message-ID: <20040707204501.GA63627@ns1.xcllnt.net> In-Reply-To: <20040707220536.A86755@newtrinity.zeist.de> References: <20040630164047.GC86725@ip.net.ua> <20040702162001.GD78489@dragon.nuxi.com> <20040702184443.GB4193@ip.net.ua> <20040702201200.GA3485@dhcp50.pn.xcllnt.net> <20040702211936.GA4962@ip.net.ua> <20040702225017.GA3828@dhcp50.pn.xcllnt.net> <20040707220536.A86755@newtrinity.zeist.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 07, 2004 at 10:05:36PM +0200, Marius Strobl wrote: > > I hit this bug also with a native compilation on sparc64 trying to > build nmap. The patch below fixes both the cross-buildworlds and > the nmap build. It's taken from the GCC gcc-3_3-branch branch > (sparc.h revision 1.215.4.4) so it can be committed to the FSF > branch in FreeBSD. It's also part of GCC 3.4 and 3.4.1. Excellent! If you didn't pester kan@ yet, feel free to start now. (kan@ cc'd). The sooner we get these tinderbox failures fixed the better... > I have no idea why GNU tar trigged the bug only when cross building > for sparc64. I noticed the code generated for the native compilation and the cross compilation differed. Probably some optimization/transformation did not happen or happened differently for one and therefore avoided (or triggered) the bug. It cannot be a 32-bit crossbuild bug if you saw it natively as well, so it must be a second order effect (of which the root cause may be that we're cross-building)... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040707204501.GA63627>