All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <andreas.faerber@web.de>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Juan Pineda <juan@logician.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 2/4] softfloat: Avoid uint16 type conflict on Darwin
Date: Tue, 01 Nov 2011 20:11:42 +0100	[thread overview]
Message-ID: <4EB0446E.8080601@web.de> (raw)
In-Reply-To: <9767C2D2-8BFD-4A17-AE4D-9C0B9A612002@sunshineco.com>

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 <andreas.faerber@web.de> 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	other threads:[~2011-11-01 19:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-31 19:17 [Qemu-devel] [PATCH v2 0/4] Cocoa patches for 1.0 Andreas Färber
2011-10-31 19:17 ` [Qemu-devel] [PATCH v2 1/4] MAINTAINERS: Add Cocoa maintainer Andreas Färber
2011-10-31 19:18 ` [Qemu-devel] [PATCH v2 2/4] softfloat: Avoid uint16 type conflict on Darwin Andreas Färber
2011-10-31 19:42   ` Peter Maydell
2011-10-31 19:17     ` Andreas Färber
2011-11-01  8:09   ` Eric Sunshine
2011-11-01 16:37     ` Andreas Färber
2011-11-01 17:59       ` [Qemu-devel] [PATCH v3 " Andreas Färber
2011-11-01 18:01         ` Peter Maydell
2011-11-01 18:05           ` Andreas Färber
2011-11-01 18:55             ` Eric Sunshine
2011-11-01 19:11               ` Andreas Färber [this message]
2011-11-01 18:17         ` Andreas Färber
2011-11-01 18:47       ` [Qemu-devel] [PATCH v2 " Eric Sunshine
2011-11-01 18:52         ` Andreas Färber
2011-11-01 19:06           ` Eric Sunshine
2011-11-01 19:25             ` Andreas Färber
2011-11-01 19:37               ` Peter Maydell
2011-11-01 19:45               ` Eric Sunshine
2011-11-01 20:21                 ` Andreas Färber
2011-11-01 19:25             ` Eric Sunshine
2011-11-01 19:32               ` Andreas Färber
2011-10-31 19:18 ` [Qemu-devel] [PATCH v2 3/4] vl.c: Guard against GThread double-initialization Andreas Färber
2011-10-31 19:18 ` [Qemu-devel] [PATCH v2 4/4] cocoa: Close sheet after image file selection Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB0446E.8080601@web.de \
    --to=andreas.faerber@web.de \
    --cc=juan@logician.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.