Date: Tue, 17 Feb 2004 12:35:45 -0600 (CST) From: "Paul Seniura" <pdseniura@techie.com> To: "Chuck Swiger" <cswiger@mac.com> Cc: Paul Seniura <pdseniura@techie.com> Subject: Re: need help on CFLAGS in /etc/make.conf please Message-ID: <20040217183545.E65B95C22@techpc04.okladot.state.ok.us> In-Reply-To: <402D070D.90506@mac.com> References: <20040213001703.616C75C3B@techpc04.okladot.state.ok.us><20040213011324.GA55948@xor.obsecurity.org><20040213035608.3AA11A38EA@scifi.homeip.net><402D070D.90506@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Chuck,
The delay in my response here was due to pest control in our building
and the three-day weekend (I have no li'l-endians at home ;) .
Chuck Swiger wrote:
> Hi, Paul--
>
> There is little point to crossposting between -questions and -hackers;
> dropping the latter. Actually, <ports@freebsd.org> is probably the most
> appropriate place...
As I look at it more & more, it'll probably be a hack job to get it to
do what I'm suggesting. ;)
I've responded to Kris with further contemplations, if you have time and
would like to chime-in, please do.
> Paul Seniura wrote:
> > My question for this discussion is specifically how to prevent
> > overriding a port's own setting for that parm, and to provide a
> > default setting -O[1] when the port does not set it at all?
>
> Well-behaved ports respect CFLAGS, meaning that you can define that variable
> in /etc/make.conf (or on the command line when you invoke make), and the port
> should use that value when building the software.
Sorry to say, I don't think you're getting my gist here. ;)
I want a default setting -O "iff"=="if and only if" the original does not
provide it. That's what "default setting" means. ;)
Also, I do not want to override the original's optimization settings either
if there was one provided -- my "default setting" isn't used in this case.
See what I mean?
And as far as i386 is concerned, it is looking like -O2 is the "maximum"
that should be attempted. Other platforms, e.g. -march=7450 I use at home,
can go -O5 without problems. At any rate, I certainly want to cut-down
anything like what Kris mentions e.g. -O999!
> If you tell us which port is broken, someone will fix it. For example, one of
> the ports I maintain the author explicitly sets -O2, but the port Makefile
> patches that via:
>
> post-patch:
> ${REINPLACE_CMD} -e 's/-O2//' ${WRKSRC}/Makefile
A msg from Richard Coleman, taken together with the GCC 3.x Known Bugs
site, is leading me to believe any bugs solely due to higher -O levels need
to be fixed by the author(s) of the software. ISTM many 'enterprising'
companies are relying on the integrity of GCC in this manner. GCC has
come a long way to earn that kind of trust. And so I would like to be
able to trust the author's settings in this regard, if I so choose
(putting on my system admin's hat).
You're changing what the author sets-up before any hack-job I invent will
even see it. Why? If I interpret what Kris said correctly, he wants you
to think GCC 3.x is the source of the bugs at -O2+. My response to him was,
essentially, to read-up on GNU's GCC 3.x Known Bugs webpage, where they
clearly state any -O bugs are much more likely to be non-ISO-compliant
source code style. The author would need to fix the source code and/or
logic in these cases so -O2 will work properly.
If my hack-job sees the result of your hack-job, it will reinsert a -O
(effectively -O1) back into the compiler options. But clearly the
original author wants -O2 here, so it ought to override my -O default, if
I allow it to.
I reiterate the notion of other platforms working fine with optimizations
and FBSD is slowing down because IMHO of some age-old assumptions about GCC
itself. As a specific example: If GCC 3.3.3 generates really fast code
on a Linux/i386 app *and* it's proven to work well, then FBSD/i386's code
should fly just as fast at the same level with no problem. Oh but y'all
are hacking the guts out of the optimization settings coming from the
author, so FBSD/i386 will never see the same end-results here.
Also I'm fussin' because I've read several KDE users's msgs about its new
slowness with 3.2. The higher-ups here would love to see this project fail
(they already ignore my ideas on getting Macs, but I digress...). We need
some _working_ performance-boosting options on i386 if we're going to show
FreeBSD in its best light.
As an aside, I volunteered to get net/tn3270 working again. Its src has
numerous violations, because no one has maintained it. On top of that, it
copies parts of /usr/src (telnet) and patches it to hopefully follow IBM's
RFCs for mainframe environments. I *really* hope to cut out these ugly
hacks once & for all. Guess how long this Puny Pentium2 takes to compile
anything... it's all 'they' will let me use here... *any* improvements in
optimized code will go a long way on these slow boxes (yes I've read the
on-line manuals on 'tuning' etc. and have already implemented as many of
those ideas as I can [am permitted] here).
Thank you,
-- Paul Seniura
System Specialist (z/OS mainly, where we have only 16 registers!)
State of Okla. D.O.T.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040217183545.E65B95C22>