Re: [libvirt] [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols

Blue Swirl <blauwirbel(a)gmail.com&gt; writes: > On Fri, Jul 27, 2012 at 3:31 PM, Anthony Liguori <aliguori(a)us.ibm.com&gt; wrote: >> Peter Maydell <peter.maydell(a)linaro.org&gt; writes: >> >>> On 27 July 2012 15:27, Anthony Liguori <aliguori(a)us.ibm.com&gt; wrote: >>>> Peter Maydell <peter.maydell(a)linaro.org&gt; writes: >>>>> The GCC manual says "Weak symbols are supported for ELF targets, >>>>> and also for a.out targets when using the GNU assembler and linker". >>>>> Have you tested this on Windows and MacOSX ? >>>> >>>> Weak symbols are supposed to be supported by mingw32. >>>> >>>> I have no idea about MacOS X. >>>> >>>> I have no way to develop or test for MacOS X using free software so I >>>> honestly don't care about it. >>> >>> My approach to this is to avoid non-standard things >> >> http://en.wikipedia.org/wiki/C99#Implementations >> >> So unless you plan on compiling QEMU with xlc, pgi, or icc, I don't >> think relying on "standard things" really helps. > > LLVM/Clang should definitely be in the plan. weak symbols are supported by clang. >> QEMU doesn't support C99, it supports GCC. There's no point in >> debating about whether we should rely on extensions or not. We already >> do--extensively. > > Not so extensively. There are a few extensions for which there is no > simple alternative (like QEMU_PACKED) but other compilers likely need > similar extensions. Then there are other extensions (like :? without > middle expression) which can be easily avoided. We should avoid to use > the non-standard extensions whenever possible. I disagree. I don't see a point to it. QEMU has never been routinely built on anything other than GCC. Why go to a lot of trouble to support a user base that doesn't exist? If someone comes along and actively maintains support for another compiler, we can revisit. But otherwise, there's no practical reason to avoid extensions.

Regards, Anthony Liguori > >> >> Regards, >> >> Anthony Liguori >> >> >>> -- if I >>> write a patch which is pretty much standard C then it's the >>> platform's problem if it mishandles it. If I write a patch >>> that uses a compiler-specific or OS-specific thing then I >>> have to also provide the relevant alternatives...so I try >>> to avoid doing that :-) >>> >>> -- PMM >> >>