From owner-freebsd-ports@FreeBSD.ORG Wed Feb 13 11:05:36 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B1111FC for ; Wed, 13 Feb 2013 11:05:36 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 52E93A9B for ; Wed, 13 Feb 2013 11:05:35 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1U5a9S-0007GQ-Tp; Wed, 13 Feb 2013 11:05:28 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U5a9S-0000ud-HI; Wed, 13 Feb 2013 11:05:22 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r1DB5Mc6094977; Wed, 13 Feb 2013 11:05:22 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r1DB5L1V094976; Wed, 13 Feb 2013 11:05:21 GMT (envelope-from mexas) Date: Wed, 13 Feb 2013 11:05:21 GMT From: Anton Shterenlikht Message-Id: <201302131105.r1DB5L1V094976@mech-cluster241.men.bris.ac.uk> To: bf1783@gmail.com, sgk@troutmask.apl.washington.edu Subject: Re: 7+ days of dogfood In-Reply-To: <20130213033933.GA89757@troutmask.apl.washington.edu> X-Spam-Score: -3.4 X-Spam-Level: --- Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 11:05:36 -0000 From sgk@troutmask.apl.washington.edu Wed Feb 13 03:40:53 2013 On Wed, Feb 13, 2013 at 02:15:08AM +0000, b.f. wrote: > On 2/13/13, Steve Kargl wrote: > > On Wed, Feb 13, 2013 at 12:18:29AM +0000, b.f. wrote: > >> ># cat /etc/make.conf|grep FFLAGS > >> >FFLAGS = -O2 -pipe -march=native -mtune=native > >> > >> Please do _not_ assign flags unconditionally in make.conf. > > > > FFLAGS is for compiling Fortran. I'm one of the people who > > has spent years working/patching gfortran. I think I might > > have a better understanding of what options to use with > > gfortran than most people. > > > > I know you have, but you are giving advice that is liable to be abused > by those who are less experienced. The flags you are adding are not > the problem -- it's the way that you are adding them -- specifically, > the assignment in the first line of your snippet, if it's applied > unconditionally. You should either be appending all of them, or > assigning them conditionally, so that they are sure to be assigned > only once, or -- preferably -- using another makefile that can't be > re-read multiple times during a build (ports/Mk/bsd.port.mk > automatically includes several makefiles that can be used for this > purpose, if you are building a port). You have been lucky not to trip > over this: every couple of months for the last several years I have > had to debug errors reported by users that arise from this problem. It > is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS, > too. Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS' Then go read about the options chosen by the various port maintainers. I specifically set FFLAGS to avoid the questionable options set in the ports. If -malign-double appears in a port, it should probably be marked as broken. If a port uses -fdefault-real-8, it should probably be marked as broken. If a port uses -ffast-math, it may have issues that are extremely difficult to debug. (I removed freebsd-current@ and added cc to ports@) Oi vey. I see, it is complicated. So on the one hand some options are risky or just wrong and must not be used. On the other there is a large number of ports, which might not even build if this is implemented, and convincing upstream that they are wrong is never easy. Is there a middle ground? What about appending the suggested options to FFLAGS in ports/MK/bsd.port.mk? Or will it make debugging ports with "questionable" options even harder? Anton