On 30 January 2014 08:00, Markus Armbruster <arm...@redhat.com> wrote: > Peter Maydell <peter.mayd...@linaro.org> 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
