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

[Charles Davis]

Douglas Gregor wrote:
> 
> 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
OK.
> 
>> 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/
You don't? Well then, I guess, to be on the safe side, I should file a
request.
> 
>> 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?
Basically, any code that defines a __stdcall function pointer typedef,
like this one for example:

../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
applies to
function types
typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
              ^
../../include/winnt.h:44:15: note: instantiated from:
#define NTAPI __stdcall
              ^../../include/windef.h:57:38: note: instantiated from:
#    define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_
arg_pointer__))                                     ^


> 
>     - Doug

Thanks.

Chip