qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2 2/4] softfloat: Avoid uint16 type conflict on Darwin
Date: Tue, 01 Nov 2011 19:52:25 +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:47, schrieb Eric Sunshine:
> On Nov 1, 2011, at 12:37 PM, Andreas Färber wrote:
>> Am 01.11.2011 09:09, schrieb Eric Sunshine:
>>> Perhaps the following alternative solution would be more palatable? It's
>>> still tremendously ugly, but is localized to cocoa.m, thus less
>>> intrusive.
>>>
>>> -- >8 --
>>> Subject: [PATCH] softfloat: Avoid uint16 type conflict on Darwin
>>>
>>> cocoa.m includes <Security/cssmconfig.h> indirectly via <Cocoa/Cocoa.h>.
>>> cssmconfig.h defines type uint16 which unfortunately conflicts with the
>>> definition in qemu's softfloat.h, thus resulting in compilation failure.
>>> To work around the problem, #define _UINT16, which informs cssmconfig.h
>>> that uint16 is already defined and that it should not apply its own
>>> definition.
>>
>> Thanks for the suggestion! _UINT16 is an interesting suggestion, however
>> softfloat's uint16 is not uint16_t but int, so I'd rather not do it that
>> way around.
>>
>> (I had also decided against the AIX path of never defining uint16 and
>> always using system definitions, since that wouldn't work outside Cocoa
>> code.)
>>
>> Do you have any thoughts about the include path issue? If we could keep
>> QEMU code from getting into #import <Cocoa/Cocoa.h> then we could
>> redefine the system type instead, in cocoa.m.
> 
> Is the intention to trust uint16 from <Security/cssmconfig.h> over the
> one softfloat.h? If so, shouldn't we be taking as many type definitions
> from <Security/cssmconfig.h> as we can rather than just this one? (I'm
> not recommending it; just trying to understand the goal.)

Short-term goal: make Darwin build 1.0 without breaking others
Long-term goal: not use uint16 etc. in QEMU at all

Don't see what you mean with "taking as many type definitions". After
uint16 I get no further conflicts for --enable-system --disable-user,
so what is there to take?

Andreas



reply via email to

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