[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/45374: -current tools using machine-local CPU CFLAGS overriding mk.conf
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>
Subject: Re: port-i386/45374: -current tools using machine-local CPU CFLAGS
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
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)...
Main Index |
Thread Index |