[cfe-dev] Building Wine with clang on Mac OS X 10.6

[Charles Davis]

Török Edwin wrote:
> On 2009-10-19 17:35, Charles Davis wrote:
>> Hi,
>>
>> I tried to build the latest Wine sources (the ones from git) with clang
>> on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
>>
>> Specifically, I get this message:
>>
>> clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
>> -D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o interlocked.o
>> interlocked.c
>> /var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
>> _interlocked_cmpxchg already defined.
>> clang: error: assembler command failed with exit code 1 (use -v to see
>> invocation)
>>
>> Looking at the wine sources, I found out that interlocked_cmpxchg() is
>> defined "extern inline" in include/wine/port.h, and is redefined in
>> libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
>> compiles fine with llvm-gcc.
>>   
> 
> Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
> 
> Best regards,
> --Edwin
Sorry about not replying to all. (Need to get into the habit...)

Anyway, I got pretty far, but now I've encountered another "extern
inline" problem. clang complains about the redefinition of
GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
defined in include/winbase.h). This is WITH -std=gnu89:

heap.c:254:15: error: redefinition of 'GetProcessHeap'
HANDLE WINAPI GetProcessHeap(void)
              ^
In file included from heap.c:59:
../../include/winbase.h:2533:29: note: previous definition is here
extern inline HANDLE WINAPI GetProcessHeap(void)
                            ^

As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.

Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?