Re: port-i386/45374: -current tools using machine-local CPU CFLAGS overriding mk.conf

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR port-i386/45374; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-i386/45374: -current tools using machine-local CPU CFLAGS
 overriding mk.conf
Date: Sun, 18 Sep 2011 12:23:39 -0400

 On Sun, 18 Sep 2011 08:20:04 +0000 (UTC)
 matthew green <mrg%eterna.com.au@localhost> wrote:
 
 >  while i'd like to fix this problem, i don't think that we ever have
 >  tried to provide this level of compatibility for the tooldir.  our
 >  src/tools are designed to run on the machine you build netbsd, not on
 >  some other system.
 >  
 >  > >Fix:
 >  > 
 >  > Currently unknown; tell GMP at configuration to not do heuristics,
 >  > or give it conservative x86 CFLAGS to use?  Or observe mk.conf provided
 >  > CFLAGS instead of ignoring them when building tools?  So that
 >  > CFLAGS+='-march=i686 -O2' would work for /usr/tools/ ...
 >  
 >  can someone have a look at what happens here?  this is also the same
 >  basic issue that people had trying to build on some OSX versions,
 >  where GMP and MPFR would choose different defaults.  clearly there's
 >  some extra we need to do for GMP -- but i don't know it well enough
 >  to really fix it, and won't have a lot of time in the near future.
 >  
 >  FWIW, setting "ABI" when configuring GMP can alter the settings it
 >  chosses, so maybe picking a valid LCD here is what we need.
 
 I think that indeed, traditionally the reason to avoid optimizations
 (and even ignore mk.conf provided CFLAGS, if any) was to avoid
 potential toolchain bugs, more than inter-machine compatibility.
 
 As long as it'd be possible to enforce mk.conf CFLAGS (at one's own
 risk, of course), in theory my problem would be fixed :)  Perhaps that
 it'd also be useful for benchmarks as custom optimizations could be
 used for the toolchain, potentially affecting the distribution building
 time...
 
 I also am not very familiar with GMP, however the package I built from
 pkgsrc observed the CFLAGS provided via /etc/mk.conf without issues.  I
 didn't previously have MPFR installed, but I just did a test and it
 also observes mk.conf CFLAGS.  Of course, that's a pkgsrc-conditional
 CFLAGS (.ifdef BSD_PKG_MK) in this case, but I also have a global one.
 
 It could perhaps simply be that GMP/MPFR take CFLAGS in consideration
 if in the environment, with the current tool building system unsetting
 it if present to avoid potential toolchain bugs?  If so, is it a
 problem in itself to just let CFLAGS survive, but set a default
 conservative one (i.e. "-O2" or even "") if absent in the parent
 environment?  It wouldn't matter to me if it also required setting
 another option to tell it to observe CFLAGS to build tools (like
 ALLOWTOOLSCFLAGS=yes or similar)...
 
 Thanks,
 -- 
 Matt