qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 2/4] softfloat: Avoid uint16 type conflict on


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v3 2/4] softfloat: Avoid uint16 type conflict on Darwin
Date: Tue, 01 Nov 2011 20:11:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Am 01.11.2011 19:55, schrieb Eric Sunshine:
> On Nov 1, 2011, at 2:05 PM, Andreas Färber wrote:
>> Am 01.11.2011 19:01, schrieb Peter Maydell:
>>> On 1 November 2011 17:59, Andreas Färber <address@hidden> wrote:
>>>> Apple's FSEvents.h has #include <Block.h>, which wants
>>>> /usr/include/Block.h but due to case-insensitive file system and
>>>> include path jungle gets QEMU's ./block.h, which in turn includes
>>>> softfloat.h indirectly.
>>>
>>> Incidentally, surely you need to fix this anyway (ie fix the
>>> include path issue somehow)?
>>
>> Yes, that's why I'm explicitly documenting it. I have no clue how to fix
>> it though. Experts' opinion welcome!
> 
> 
> It probably is not a good idea to emphasize the particular #include
> stack issued by this one build environment (presumably XCode on Lion?)
> so loudly in the commit message. The type redefinition error will
> manifest regardless of #include ordering and regardless of whether or
> not ./block.h is picked up accidentally instead of <Block.h>. For
> instance, on Leopard with XCode 3.1.4, the #include stack emitted with
> the error message is entirely different even though the underlying issue
> is the same:
> 
>   OBJC  ui/cocoa.o
> In file included from ./bswap.h:8,
>                  from ./qemu-common.h:107,
>                  from ui/cocoa.m:29:
> /Users/sunshine/Desktop/qemu/fpu/softfloat.h:60: error: conflicting
> types for 'uint16'
> /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:68:
> error: previous declaration of 'uint16' was here
> make: *** [ui/cocoa.o] Error 1
> 
> In fact, on Leopard, FSEvents.h does not #include <Block.h>, so focusing
> on it in the log message is misleading.

My point is, that's the reason it needs to be fixed *this* way and not
in cocoa.m like you'd expect. If it doesn't show up in git-blame, people
will not understand and "clean up". It's always just an example since it
includes user-specific paths - here Snow Leopard. Rewording.

AF



reply via email to

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