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
