Re: [Qemu-devel] [PATCH v1 2/2] Revert "error: Don't use error_report() for assertion msgs."

[Peter Maydell]

On 30 January 2014 08:00, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> [MacOSX doesn't pull in common symbols from .o files in
>> .a archives]

> Not ugly, but a sensible move (in my opinion) regardless of this
> specific issue: compile with -fno-common.  Then both become not common.
>
> `-fno-common'
>      In C code, controls the placement of uninitialized global
>      variables.  Unix C compilers have traditionally permitted multiple
>      definitions of such variables in different compilation units by
>      placing the variables in a common block.  This is the behavior
>      specified by `-fcommon', and is the default for GCC on most
>      targets.  On the other hand, this behavior is not required by ISO
>      C, and on some targets may carry a speed or code size penalty on
>      variable references.  The `-fno-common' option specifies that the
>      compiler should place uninitialized global variables in the data
>      section of the object file, rather than generating them as common
>      blocks.  This has the effect that if the same variable is declared
>      (without `extern') in two different compilations, you will get a
>      multiple-definition error when you link them.  In this case, you
>      must compile with `-fcommon' instead.  Compiling with
>      `-fno-common' is useful on targets for which it provides better
>      performance, or if you wish to verify that the program will work
>      on other systems that always treat uninitialized variable
>      declarations this way.

This seems to work. Judging by that description, we could build
with -fno-common everywhere. That would mean that accidentally
declaring the same variable in two compilation units was a compile
failure everywhere rather than just on MacOSX, which I think is
preferable.

Is there any reason we shouldn't just build with -fno-common
for all platforms and compilers?

thanks
-- PMM