From owner-freebsd-doc@FreeBSD.ORG Tue Apr 12 17:37:16 2005 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4D5816A4CE for ; Tue, 12 Apr 2005 17:37:16 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A905243D2F for ; Tue, 12 Apr 2005 17:37:15 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail invoked by alias); 12 Apr 2005 17:37:13 -0000 Received: from p508BB620.dip.t-dialin.net (EHLO lofi.dyndns.org) [80.139.182.32] by mail.gmx.net (mp005) with SMTP; 12 Apr 2005 19:37:13 +0200 X-Authenticated: #443188 Received: from [192.168.8.4] (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.13.3/8.12.10) with ESMTP id j3CHawWN023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 19:36:59 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <425C0739.9010006@gmx.net> Date: Tue, 12 Apr 2005 19:36:57 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Mikhail Teterin References: <200504120533.j3C5XNFL008134@corbulon.video-collage.com> <200504120805.23933.michaelnottebrock@gmx.net> <200504121157.34740.mi+mx@aldan.algebra.com> In-Reply-To: <200504121157.34740.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Y-GMX-Trusted: 0 cc: doc@freebsd.org cc: Scott Long cc: Roman Neuhauser cc: freebsd-ports@freebsd.org Subject: Re: mozilla's install hanging on amd64 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 17:37:17 -0000 Mikhail Teterin wrote: > So, now you accuse me of lying... The only potentially -march-related problem > I had before was with mozilla and the flag was -march=p2. Interesting. > It would build and > install, but would not start. FWIW, a root-owned ~/.mozilla can cause this behaviour, too... I have been bitten by that multiple times, both with mozilla and firefox. Building with sudo lets this happen easily :-\. > I still have the machine... When I reported > this error to gnome@ a year or so ago, I was similarly "yelled" at, that > -march setting is not supposed to work... No, just not supported (by us, the porters). "Not supported" means "if it breaks and turning off fixes it, then you have the choice of coming up with a fix/workaround yourself and submitting it to the porters / upstream developers which may or may not use it at their discretion or not use -march for the respective port. It should be obvious to you why almost everybody, be it upstream developer or port-maintainer is so hesitant to make a commitment to all possible code-generation options and other gimmicks that gcc offers - they *do*, like it or not, occasionally trigger bugs, which usually are very hard to reproduce and harder to nail down. >>>make.conf(5) documents it, it should work. Period. >> >>make.conf(5) documents CFLAGS. What would you like to infer from that fact? > > > In its documentation of CFLAGS, the man-page warns, that levels other than "-O > and -O2" are not supported. But it doesn't warn about all the other optimization switches you could specify. > There is nothing about any risk of > processor-specific flags like -march, and rightly so. *sigh*. I don't get how can you seriously claim that using a specialised code-generation setting, which obviously must receive less developer-side and real-world testing than the standard one does not entail a risk. > CPUTYPE's paragraph rightly encourages setting the variable to the actual CPU > flavor. Everything except the mozilla port (and I have 222 ports installed on > this machine already) built fine. Few things have self-test capabilities, but > those, that do (Perl, lcms) passed their tests. > > >>If a compiler optimization produces a bad binary while the same compiler >>with the switch off does not (or a different version of the compiler with >>the switch does not), the compiler usually *is* to blame. > > > Scott has responded to this already. Aliasing rules shouldn't be influenced by -march. In fact, I shouldn't have said "optimization" there, since -march (should) not trigger architecture-specific optimization, just code-generation (i.e. things like the used instruction set, instruction scheduling, register allocation). And yet that's plenty enough to hide bugs in, sometimes nasty enough to even cause internal compiler errors. I myself have filed -march related bugreports against gcc in the past. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org