Building Wine with clang on Mac OS X 10.6

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.

Should I file a bug, or is this a known issue (like bug 2742)?

Thanks.

Chip

Does it compile with -std=gnu89? (clang defaults to gnu99 I think).

Best regards,
--Edwin

Török Edwin 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?

Török Edwin 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

Douglas Gregor wrote:

Török Edwin 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

Douglas Gregor wrote:

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.

Thanks, I see it at http://llvm.org/bugs/show_bug.cgi?id=5254

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

This boils down to, e.g.,

  typedef void (__attribute__((stdcall)) * callback)(int, int);

which we complain about:

stdcall.c:1:30: warning: 'stdcall' attribute only applies to function types
typedef void (__attribute__((stdcall)) * callback)(int, int);
                              ^

Basically, we don't yet have a way to encode the stdcall attribute in the type system, so we can't form a function pointer to a stdcall function. I've filed a PR for this, here:

  http://llvm.org/bugs/show_bug.cgi?id=5310

  - Doug

Douglas Gregor wrote:

Douglas Gregor wrote:

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.

Thanks, I see it at http://llvm.org/bugs/show_bug.cgi?id=5254

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

This boils down to, e.g.,

    typedef void (__attribute__((stdcall)) * callback)(int, int);

which we complain about:

stdcall.c:1:30: warning: 'stdcall' attribute only applies to function types
typedef void (__attribute__((stdcall)) * callback)(int, int);
                             ^

Basically, we don't yet have a way to encode the stdcall attribute in
the type system, so we can't form a function pointer to a stdcall
function. I've filed a PR for this, here:

    http://llvm.org/bugs/show_bug.cgi?id=5310

You did? But I already filed one here:

      http://llvm.org/bugs/show_bug.cgi?id=5280

And then someone filed a dupe here:

      http://llvm.org/bugs/show_bug.cgi?id=5303

    - Doug

Took you a while to get back to me on this. Oh well, I've seen the
commit logs. You guys are busy with C++ support, so this is
understandable. Anyway, thanks.

Chip

Douglas Gregor wrote:

Basically, we don't yet have a way to encode the stdcall attribute in
the type system, so we can't form a function pointer to a stdcall
function. I've filed a PR for this, here:

   http://llvm.org/bugs/show_bug.cgi?id=5310

You did? But I already filed one here:

     http://llvm.org/bugs/show_bug.cgi?id=5280

Yikes, my mistake. Thanks for pointing that out.

And then someone filed a dupe here:

     http://llvm.org/bugs/show_bug.cgi?id=5303

Both mine and 5303 closed as duplicates.

Took you a while to get back to me on this.

That shouldn't be typical; I was away at a C++ committee meeting for the week, so many things sent on the 19th or later got delayed.

  - Doug