From s...@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 <s...@troutmask.apl.washington.edu> 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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to