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

[Douglas Gregor]

On Oct 19, 2009, at 8:33 AM, Charles Davis wrote:

> 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)
>                           ^

Clang does not implement this feature yet. I've filed a bug report  
about it here:

  http://llvm.org/PR5253

> 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.

We don't have support for this attribute in Clang, and I don't know  
whether it is necessary for what you're doing. Please file an  
extension request at

	http://llvm.org/bugs/

> 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?

Not one I know about. What diagnostics on what code?

	- Doug