ui/cocoa.m: Fix recent compile breakage

Il 22/04/2013 13:51, Peter Maydell ha scritto:
> On 22 April 2013 00:03, Andreas Färber <andreas.faerber@web.de> wrote:
>> Even after this has been applied, things are still not building for me.
>>
>> I'm seeing CC trace/generated-events.o failing with "error: parameter
>> name omitted" for trace_apic_local_deliver, trace_usb_xhci_queue_event,
>> trace_megasas_msix_raise and trace_spapr_pci_msi_setup, plus a warning
>> that trace_event_count is being declared twice.
> 
> I suspect that whatever compiler you're using here treats 'vector'
> as a magic word, so when it sees a prototype like
>   static inline void trace_megasas_msix_raise(int vector)
> 
> it's expecting that 'vector' is an attribute of the type and
> it wants "int vector foo", hence the error message.
> 
> You could test this theory by changing all the 'vector's in
> trace-events to 'vec' instead and rebuilding.

The culprit is likely altivec.h.

Something like this should fix it:


Paolo

Am 22.04.2013 14:32, schrieb Paolo Bonzini:
> Il 22/04/2013 13:51, Peter Maydell ha scritto:
>> On 22 April 2013 00:03, Andreas Färber <andreas.faerber@web.de> wrote:
>>> Even after this has been applied, things are still not building for me.
>>>
>>> I'm seeing CC trace/generated-events.o failing with "error: parameter
>>> name omitted" for trace_apic_local_deliver, trace_usb_xhci_queue_event,
>>> trace_megasas_msix_raise and trace_spapr_pci_msi_setup, plus a warning
>>> that trace_event_count is being declared twice.
>>
>> I suspect that whatever compiler you're using here treats 'vector'
>> as a magic word, so when it sees a prototype like
>>   static inline void trace_megasas_msix_raise(int vector)
>>
>> it's expecting that 'vector' is an attribute of the type and
>> it wants "int vector foo", hence the error message.
>>
>> You could test this theory by changing all the 'vector's in
>> trace-events to 'vec' instead and rebuilding.
> 
> The culprit is likely altivec.h.
> 
> Something like this should fix it:

That works fine, but one error remains:

  LINK  i386-softmmu/qemu-system-i386
Undefined symbols:
  "___sync_val_compare_and_swap", referenced from:
      _migrate_finish_set_state in migration.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [qemu-system-i386] Error 1
make: *** [subdir-i386-softmmu] Error 2

That seems unrelated, so I'll send out this patch later.

Thanks,
Andreas

> 
> diff --git a/include/qemu-common.h b/include/qemu-common.h
> index 2cfb1f0..6c23b1b 100644
> --- a/include/qemu-common.h
> +++ b/include/qemu-common.h
> @@ -436,12 +436,18 @@
>  /* vector definitions */
>  #ifdef __ALTIVEC__
>  #include <altivec.h>
> -#define VECTYPE        vector unsigned char
> +/* The altivec.h header says we're allowed to undef these for
> + * C++ compatibility.  Here we don't care about C++, but we
> + * undef them anyway to avoid namespace pollution.
> + */
> +#undef vector
> +#undef pixel
> +#undef bool
> +#define VECTYPE        __vector unsigned char
>  #define SPLAT(p)       vec_splat(vec_ld(0, p), 0)
>  #define ALL_EQ(v1, v2) vec_all_eq(v1, v2)
>  /* altivec.h may redefine the bool macro as vector type.
>   * Reset it to POSIX semantics. */
> -#undef bool
>  #define bool _Bool
>  #elif defined __SSE2__
>  #include <emmintrin.h>
> 
> Paolo
>

On 5 May 2013 17:29, Andreas Färber <andreas.faerber@web.de> wrote:
> That works fine, but one error remains:
>
>   LINK  i386-softmmu/qemu-system-i386
> Undefined symbols:
>   "___sync_val_compare_and_swap", referenced from:
>       _migrate_finish_set_state in migration.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [qemu-system-i386] Error 1
> make: *** [subdir-i386-softmmu] Error 2

...does this gcc predate the atomic builtins? That
could be awkward.

-- PMM

Am 05.05.2013 18:47, schrieb Peter Maydell:
> On 5 May 2013 17:29, Andreas Färber <andreas.faerber@web.de> wrote:
>> That works fine, but one error remains:
>>
>>   LINK  i386-softmmu/qemu-system-i386
>> Undefined symbols:
>>   "___sync_val_compare_and_swap", referenced from:
>>       _migrate_finish_set_state in migration.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> make[1]: *** [qemu-system-i386] Error 1
>> make: *** [subdir-i386-softmmu] Error 2
> 
> ...does this gcc predate the atomic builtins? That
> could be awkward.

Oh, my fault: My 32-bit build script was not supplying --cc=gcc-4.2, so
it was using 4.0.1 instead of 4.2.1.

Andreas