[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Force -O0 flags, inhibit the default -O2 flags

From: Bob Friesenhahn
Subject: Re: Force -O0 flags, inhibit the default -O2 flags
Date: Tue, 27 Sep 2005 22:09:24 -0500 (CDT)

On Tue, 27 Sep 2005, Brian wrote:

We have several files which are not able to be optimized, and when our mac
mini tries to build the project it chokes up when attempting to do so. It
seems incorrect to say that the package developer is the least qualified to
judge compiler flags, and it also seems to avoid the point. The package
developer should be able to override the autotools, and the user should be
able to override the developer. It is not a matter of qualification, it is a
matter of the chain of command. Right now the chain of command is user -->
autotools --> developer. In reality it should be user --> developer -->

What compiler flags do you use to disable optimization for the host matching the config.guess tripplet hppa2.0w-hp-hpux11.11 and using the vendor (HP) C and C++ compiler? Does it also have the same optimization problem?

If a user has a Mac G5 (2.7GHz) with 8 GB of RAM rather than a Mac Mini, does the compiler also fail to optimize the module?

Is it possible that the compiler which has the problem will be fixed by next year so that the developer provided option is no longer any use?

Recently I encountered several projects which insisted on inserting -mv8 into the compilation options because I was compiling on a SPARC system and the developer knew best. Problem is, GCC does not support -mv8 any more so the project does not compile at all. Besides, my SPARC is not a v8 architecture CPU. Solution: manually edit the configure script.

In spite of arguments to the contrary, the developer does have absolute power over compiler flags since he has control over the configure script. As with most forms of absolute power, it is best used in moderation.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]