From owner-freebsd-questions@FreeBSD.ORG Sun May 4 10:42:54 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A7D37B401 for ; Sun, 4 May 2003 10:42:54 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC5043FBF for ; Sun, 4 May 2003 10:42:52 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([129.44.60.214]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030504174252.HSJC17739.pop018.verizon.net@mac.com> for ; Sun, 4 May 2003 12:42:52 -0500 Message-ID: <3EB5511A.4090001@mac.com> Date: Sun, 04 May 2003 13:42:50 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd Questions References: <1051150476.23923.10.camel@jupiter.main.gaddis.org> <20030428092345.K22519-100000@diana.northnetworks.ca> <20030503002817.GA734@joloxbox.joshualokken.com> <20030503053612.GA1042@nina.la3sg.net> <20030503141342.95756.qmail@gaddis.org> <20030504155209.591.qmail@gaddis.org> In-Reply-To: <20030504155209.591.qmail@gaddis.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [129.44.60.214] at Sun, 4 May 2003 12:42:51 -0500 Subject: Re: make buildworld fails on 4.8-release X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2003 17:42:54 -0000 Jeremy Gaddis wrote: >>> CPUTYPE=i686 >>> NOPROFILE=true [ ... ] > Still don't know why those two lines would cause it > to fail, especially since I took them straight out of > some {documentation|HOWTO|handbook|something}. Sometimes the compiler has problems with higher optimization levels, some of which are implied by the CPU-specific scheduling and such the "-mcpu=i686" ("-march=i686"?) your CPUTYPE setting produces. If the compilation terminates, it's either a bug with gcc itself, or possibly an interaction with the source code explicitly trying to do something else. For a possible example, OpenSSL's hand-tuned assembly and specific -m flags it wants instead. If the system compiles but then panics or simply encounters very odd, intermittant bugs, because the kernel was optimized too highly, that's harder to diagnose. Perhaps some critical reference to a volatile memory location got optimized away because it didn't look like it was doing anything, or the compiler failed to understand pointer aliasing when the kernel is adjusting the VM page tables, or god knows what, well, it'd be really nice to identify and solve those bugs, but it's also hard to reproduce them and track down the causes. Please do try, however. :-) "Warranty: If this software breaks, you get to keep both pieces." -- -Chuck