public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Another issue with CLANG
@ 2013-01-11 12:55 Angelo Graziosi
  2013-01-13 14:31 ` Jon TURNEY
  0 siblings, 1 reply; 8+ messages in thread
From: Angelo Graziosi @ 2013-01-11 12:55 UTC (permalink / raw)
  To: Cygwin

An application which need to be built with clang++, fails to build when 
it includes glx.h and indirectly windows.h headers like in the test case 
shown below.

In short, X11/Xlib.h define Status as a macro (an alias for int) instead 
rpcdce.h uses Status a a pointer variable name...

Ciao,
  Angelo.

$ cat foo.cxx
#include <GL/glx.h>
#include <windows.h>


int foo()
{
   return 0;
}

$ clang++ -D_X86_=1 -c foo.cxx -o foo.o
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:70:
/usr/include/w32api/rpcdce.h:142:88: error: expected ')'
   ...RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID *TypeUuid,RPC_STATUS *Status);
                                                                    ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:142:43: note: to match this '('
   typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID...
                                           ^
/usr/include/w32api/rpcdce.h:471:145: error: expected ')'
   ...__LONG32 KeyVer,void **Key,RPC_STATUS *Status);
                                             ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:471:54: note: to match this '('
   typedef void (__RPC_API *RPC_AUTH_KEY_RETRIEVAL_FN)(void 
*Arg,unsigned short...
                                                      ^
/usr/include/w32api/rpcdce.h:513:81: error: expected ')'
   ...int RPC_ENTRY UuidCompare(UUID *Uuid1,UUID *Uuid2,RPC_STATUS *Status);
                                                                    ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:513:44: note: to match this '('
   RPCRTAPI signed int RPC_ENTRY UuidCompare(UUID *Uuid1,UUID 
*Uuid2,RPC_STATUS...
                                            ^
/usr/include/w32api/rpcdce.h:515:72: error: expected ')'
   RPCRTAPI int RPC_ENTRY UuidEqual(UUID *Uuid1,UUID *Uuid2,RPC_STATUS 
*Status);
                                                                        ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:515:35: note: to match this '('
   RPCRTAPI int RPC_ENTRY UuidEqual(UUID *Uuid1,UUID *Uuid2,RPC_STATUS 
*Status);
                                   ^
/usr/include/w32api/rpcdce.h:516:69: error: expected ')'
   RPCRTAPI unsigned short RPC_ENTRY UuidHash(UUID *Uuid,RPC_STATUS 
*Status);
                                                                     ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:516:45: note: to match this '('
   RPCRTAPI unsigned short RPC_ENTRY UuidHash(UUID *Uuid,RPC_STATUS 
*Status);
                                             ^
/usr/include/w32api/rpcdce.h:517:59: error: expected ')'
   RPCRTAPI int RPC_ENTRY UuidIsNil(UUID *Uuid,RPC_STATUS *Status);
                                                           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:517:35: note: to match this '('
   RPCRTAPI int RPC_ENTRY UuidIsNil(UUID *Uuid,RPC_STATUS *Status);
                                   ^
/usr/include/w32api/rpcdce.h:547:140: error: expected ')'
   ...__LONG32 RequestedMgmtOperation,RPC_STATUS *Status);
                                                  ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
/usr/include/w32api/rpcdce.h:547:53: note: to match this '('
   typedef int (__RPC_API *RPC_MGMT_AUTHORIZATION_FN)(RPC_BINDING_HANDLE...
                                                     ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:70:
In file included from /usr/include/w32api/rpcdce.h:623:
/usr/include/w32api/rpcdcep.h:220:62: error: cannot combine with previous
       'type-name' declaration specifier
   RPCRTAPI __LONG32 RPC_ENTRY I_RpcMapWin32Status(RPC_STATUS Status);
                                                              ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:87:
/usr/include/w32api/rpcasync.h:118:11: error: cannot combine with previous
       'type-name' declaration specifier
     ULONG Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:97:
In file included from /usr/include/w32api/winscard.h:10:
In file included from /usr/include/w32api/wtypes.h:8:
In file included from /usr/include/w32api/rpcndr.h:21:
/usr/include/w32api/rpcnsip.h:21:81: error: cannot combine with previous
       'type-name' declaration specifier
   ...RPC_ENTRY I_RpcNsRaiseException(PRPC_MESSAGE Message,RPC_STATUS 
Status);
                                                                      ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:97:
In file included from /usr/include/w32api/winscard.h:10:
In file included from /usr/include/w32api/wtypes.h:8:
/usr/include/w32api/rpcndr.h:674:160: error: cannot combine with previous
       'type-name' declaration specifier
   ...*pCommStatus,unsigned __LONG32 *pFaultStatus,RPC_STATUS Status);
                                                              ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:56:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:80:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:240:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:256:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:282:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
In file included from foo.cxx:2:
In file included from /usr/include/w32api/windows.h:102:
/usr/include/w32api/winspool.h:308:11: error: cannot combine with previous
       'type-name' declaration specifier
     DWORD Status;
           ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^
17 errors generated.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-11 12:55 Another issue with CLANG Angelo Graziosi
@ 2013-01-13 14:31 ` Jon TURNEY
  2013-01-13 14:44   ` Angelo Graziosi
  0 siblings, 1 reply; 8+ messages in thread
From: Jon TURNEY @ 2013-01-13 14:31 UTC (permalink / raw)
  To: cygwin; +Cc: angelo.graziosi

On 11/01/2013 12:54, Angelo Graziosi wrote:
> An application which need to be built with clang++, fails to build when it
> includes glx.h and indirectly windows.h headers like in the test case shown
> below.
> 
> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
> rpcdce.h uses Status a a pointer variable name...

I don't think there's anything clang-specific about this problem.  The same
issue can be seen with gcc.

If your application needs both Xlib and Win32 interfaces, you should include
<X11/Xwindows.h> rather than <windows.h>, which wraps any conflicting
declarations.

(xcb uses a sensible namespace, so this is not necessary for applications
which use xcb and Win32.)

You probably need the latest upstream x11proto (not yet packaged for cygwin)
for this wrapping to work correctly with the mingw-w64 w32api headers [1]

Alternatively you can work around this yourself e.g. as in [2]

> $ cat foo.cxx
> #include <GL/glx.h>
> #include <windows.h>
> 
> 
> int foo()
> {
>   return 0;
> }
> 
> $ clang++ -D_X86_=1 -c foo.cxx -o foo.o

[1]
http://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=c0dd615fddb6fa487d1a914c6928f3843489725e
[2]
http://cgit.freedesktop.org/~jturney/xserver/commit/?h=cygwin-patches-for-1.13&id=c493cd82c5b512efad284304f19349cc84a2c63d

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-13 14:31 ` Jon TURNEY
@ 2013-01-13 14:44   ` Angelo Graziosi
  2013-01-13 15:21     ` Jon TURNEY
  0 siblings, 1 reply; 8+ messages in thread
From: Angelo Graziosi @ 2013-01-13 14:44 UTC (permalink / raw)
  To: cygwin; +Cc: Jon TURNEY

Il 13/01/2013 15.31, Jon TURNEY ha scritto:
> On 11/01/2013 12:54, Angelo Graziosi wrote:
>> An application which need to be built with clang++, fails to build when it
>> includes glx.h and indirectly windows.h headers like in the test case shown
>> below.
>>
>> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
>> rpcdce.h uses Status a a pointer variable name...
>
> I don't think there's anything clang-specific about this problem.  The same
> issue can be seen with gcc.
>
> If your application needs both Xlib and Win32 interfaces, you should include
> <X11/Xwindows.h> rather than <windows.h>, which wraps any conflicting
> declarations.
>
> (xcb uses a sensible namespace, so this is not necessary for applications
> which use xcb and Win32.)
>
> You probably need the latest upstream x11proto (not yet packaged for cygwin)
> for this wrapping to work correctly with the mingw-w64 w32api headers [1]
>
> Alternatively you can work around this yourself e.g. as in [2]


Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the 
true application those headers were included indirectly... :-(

In file included from input_line_87:1:
In file included from include/TX11GL.h:29:
In file included from /usr/include/GL/glx.h:45:
In file included from /usr/include/w32api/GL/gl.h:13:
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:70:
/usr/include/w32api/rpcdce.h:142:88: error: expected ')'
   typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID 
*TypeUuid,RPC_STATUS *Status);
 
                 ^
/usr/include/X11/Xlib.h:87:16: note: expanded from macro 'Status'
#define Status int
                ^

Ciao,
  Angelo.

>
>> $ cat foo.cxx
>> #include <GL/glx.h>
>> #include <windows.h>
>>
>>
>> int foo()
>> {
>>    return 0;
>> }
>>
>> $ clang++ -D_X86_=1 -c foo.cxx -o foo.o
>
> [1]
> http://cgit.freedesktop.org/xorg/proto/xproto/commit/?id=c0dd615fddb6fa487d1a914c6928f3843489725e
> [2]
> http://cgit.freedesktop.org/~jturney/xserver/commit/?h=cygwin-patches-for-1.13&id=c493cd82c5b512efad284304f19349cc84a2c63d
>


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-13 14:44   ` Angelo Graziosi
@ 2013-01-13 15:21     ` Jon TURNEY
  2013-01-14 12:44       ` Angelo Graziosi
  0 siblings, 1 reply; 8+ messages in thread
From: Jon TURNEY @ 2013-01-13 15:21 UTC (permalink / raw)
  To: cygwin; +Cc: angelo.graziosi

On 13/01/2013 14:44, Angelo Graziosi wrote:
> Il 13/01/2013 15.31, Jon TURNEY ha scritto:
>> On 11/01/2013 12:54, Angelo Graziosi wrote:
>>> An application which need to be built with clang++, fails to build when it
>>> includes glx.h and indirectly windows.h headers like in the test case shown
>>> below.
>>>
>>> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
>>> rpcdce.h uses Status a a pointer variable name...
>>
>> I don't think there's anything clang-specific about this problem.  The same
>> issue can be seen with gcc.
>>
>> If your application needs both Xlib and Win32 interfaces, you should include
>> <X11/Xwindows.h> rather than <windows.h>, which wraps any conflicting
>> declarations.
>>
>> (xcb uses a sensible namespace, so this is not necessary for applications
>> which use xcb and Win32.)
>>
>> You probably need the latest upstream x11proto (not yet packaged for cygwin)
>> for this wrapping to work correctly with the mingw-w64 w32api headers [1]
>>
>> Alternatively you can work around this yourself e.g. as in [2]
> 
> 
> Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true
> application those headers were included indirectly... :-(
> 
> In file included from input_line_87:1:
> In file included from include/TX11GL.h:29:
> In file included from /usr/include/GL/glx.h:45:
> In file included from /usr/include/w32api/GL/gl.h:13:

This looks very wrong, mixing native and X GL headers isn't going to work.

Assuming you mean to build an X application, this should be finding
/usr/include/GL/gl.h, so maybe an include path issue?

> In file included from /usr/include/w32api/windows.h:88:
> In file included from /usr/include/w32api/rpc.h:70:
> /usr/include/w32api/rpcdce.h:142:88: error: expected ')'
>   typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID
> *TypeUuid,RPC_STATUS *Status);

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-13 15:21     ` Jon TURNEY
@ 2013-01-14 12:44       ` Angelo Graziosi
  2013-01-14 13:43         ` Jon TURNEY
  0 siblings, 1 reply; 8+ messages in thread
From: Angelo Graziosi @ 2013-01-14 12:44 UTC (permalink / raw)
  To: cygwin; +Cc: Jon TURNEY

Il 13/01/2013 16.20, Jon TURNEY ha scritto:
> On 13/01/2013 14:44, Angelo Graziosi wrote:
>> Il 13/01/2013 15.31, Jon TURNEY ha scritto:
>>> On 11/01/2013 12:54, Angelo Graziosi wrote:
>>>> An application which need to be built with clang++, fails to build when it
>>>> includes glx.h and indirectly windows.h headers like in the test case shown
>>>> below.
>>>>
>>>> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
>>>> rpcdce.h uses Status a a pointer variable name...
>>>
>>> I don't think there's anything clang-specific about this problem.  The same
>>> issue can be seen with gcc.
>>>
>>> If your application needs both Xlib and Win32 interfaces, you should include
>>> <X11/Xwindows.h> rather than <windows.h>, which wraps any conflicting
>>> declarations.
>>>
>>> (xcb uses a sensible namespace, so this is not necessary for applications
>>> which use xcb and Win32.)
>>>
>>> You probably need the latest upstream x11proto (not yet packaged for cygwin)
>>> for this wrapping to work correctly with the mingw-w64 w32api headers [1]
>>>
>>> Alternatively you can work around this yourself e.g. as in [2]
>>
>>
>> Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true
>> application those headers were included indirectly... :-(
>>
>> In file included from input_line_87:1:
>> In file included from include/TX11GL.h:29:
>> In file included from /usr/include/GL/glx.h:45:
>> In file included from /usr/include/w32api/GL/gl.h:13:
>
> This looks very wrong, mixing native and X GL headers isn't going to work.
>
> Assuming you mean to build an X application, this should be finding
> /usr/include/GL/gl.h, so maybe an include path issue?

For the record...

ROOT guys have fixed this issue with the following patch to their 
patched version of llvm/clang:

$ cat InitHeaderSearch.cpp.diff
--- 
ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 
    2013-01-01 11:50:05.000000000 +0100
+++ 
root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 
       2013-01-14 12:10:43.906250000 +0100
@@ -305,7 +305,8 @@
    case llvm::Triple::RTEMS:
      break;
    case llvm::Triple::Cygwin:
-    AddPath("/usr/include/w32api", System, true, false, false);
+    // The headers in w32api/ are not cygwin-compatible (but native)
+    //AddPath("/usr/include/w32api", System, true, false, false);
      break;
    case llvm::Triple::MinGW32: {
        // mingw-w64 crt include paths

Ciao,
  Angelo.


>
>> In file included from /usr/include/w32api/windows.h:88:
>> In file included from /usr/include/w32api/rpc.h:70:
>> /usr/include/w32api/rpcdce.h:142:88: error: expected ')'
>>    typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID
>> *TypeUuid,RPC_STATUS *Status);


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-14 12:44       ` Angelo Graziosi
@ 2013-01-14 13:43         ` Jon TURNEY
  2013-01-15  0:31           ` Yaakov
  2013-01-15 14:45           ` Angelo Graziosi
  0 siblings, 2 replies; 8+ messages in thread
From: Jon TURNEY @ 2013-01-14 13:43 UTC (permalink / raw)
  To: cygwin; +Cc: angelo.graziosi

On 14/01/2013 11:47, Angelo Graziosi wrote:
> Il 13/01/2013 16.20, Jon TURNEY ha scritto:
>> On 13/01/2013 14:44, Angelo Graziosi wrote:
>>> Il 13/01/2013 15.31, Jon TURNEY ha scritto:
>>>> On 11/01/2013 12:54, Angelo Graziosi wrote:
>>>>> An application which need to be built with clang++, fails to build when it
>>>>> includes glx.h and indirectly windows.h headers like in the test case shown
>>>>> below.
>>>>>
>>>>> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
>>>>> rpcdce.h uses Status a a pointer variable name...
>>>>
>>>> I don't think there's anything clang-specific about this problem.  The same
>>>> issue can be seen with gcc.
>>>>
>>>> If your application needs both Xlib and Win32 interfaces, you should include
>>>> <X11/Xwindows.h> rather than <windows.h>, which wraps any conflicting
>>>> declarations.
>>>>
>>>> (xcb uses a sensible namespace, so this is not necessary for applications
>>>> which use xcb and Win32.)
>>>>
>>>> You probably need the latest upstream x11proto (not yet packaged for cygwin)
>>>> for this wrapping to work correctly with the mingw-w64 w32api headers [1]
>>>>
>>>> Alternatively you can work around this yourself e.g. as in [2]
>>>
>>>
>>> Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true
>>> application those headers were included indirectly... :-(
>>>
>>> In file included from input_line_87:1:
>>> In file included from include/TX11GL.h:29:
>>> In file included from /usr/include/GL/glx.h:45:
>>> In file included from /usr/include/w32api/GL/gl.h:13:
>>
>> This looks very wrong, mixing native and X GL headers isn't going to work.
>>
>> Assuming you mean to build an X application, this should be finding
>> /usr/include/GL/gl.h, so maybe an include path issue?
> 
> For the record...
> 
> ROOT guys have fixed this issue with the following patch to their patched
> version of llvm/clang:
> 
> $ cat InitHeaderSearch.cpp.diff
> --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp   
> 2013-01-01 11:50:05.000000000 +0100
> +++
> root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
>       2013-01-14 12:10:43.906250000 +0100
> @@ -305,7 +305,8 @@
>    case llvm::Triple::RTEMS:
>      break;
>    case llvm::Triple::Cygwin:
> -    AddPath("/usr/include/w32api", System, true, false, false);
> +    // The headers in w32api/ are not cygwin-compatible (but native)
> +    //AddPath("/usr/include/w32api", System, true, false, false);

Well, ok.  But this comment is almost completely wrong.

cygwin clang has /usr/include/w32api in the default include path (try
compiling your test program with clang -v), and since it appears *after*
/usr/include, including glx.h works correctly.

I have no idea what the right way to solve this problem is.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-14 13:43         ` Jon TURNEY
@ 2013-01-15  0:31           ` Yaakov
  2013-01-15 14:45           ` Angelo Graziosi
  1 sibling, 0 replies; 8+ messages in thread
From: Yaakov @ 2013-01-15  0:31 UTC (permalink / raw)
  To: cygwin

On Mon, 14 Jan 2013 13:43:26 +0000, Jon TURNEY wrote:
> On 14/01/2013 11:47, Angelo Graziosi wrote:
> > For the record...
> > 
> > ROOT guys have fixed this issue with the following patch to their patched
> > version of llvm/clang:
> > 
> > $ cat InitHeaderSearch.cpp.diff
> > --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp   
> > 2013-01-01 11:50:05.000000000 +0100
> > +++
> > root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
> >       2013-01-14 12:10:43.906250000 +0100
> > @@ -305,7 +305,8 @@
> >    case llvm::Triple::RTEMS:
> >      break;
> >    case llvm::Triple::Cygwin:
> > -    AddPath("/usr/include/w32api", System, true, false, false);
> > +    // The headers in w32api/ are not cygwin-compatible (but native)
> > +    //AddPath("/usr/include/w32api", System, true, false, false);
> 
> Well, ok.  But this comment is almost completely wrong.
> 
> cygwin clang has /usr/include/w32api in the default include path (try
> compiling your test program with clang -v), and since it appears *after*
> /usr/include, including glx.h works correctly.
> 
> I have no idea what the right way to solve this problem is.

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=blob;f=3.1-cygwin-includes.patch;h=1444765;hb=HEAD


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Another issue with CLANG
  2013-01-14 13:43         ` Jon TURNEY
  2013-01-15  0:31           ` Yaakov
@ 2013-01-15 14:45           ` Angelo Graziosi
  1 sibling, 0 replies; 8+ messages in thread
From: Angelo Graziosi @ 2013-01-15 14:45 UTC (permalink / raw)
  To: cygwin; +Cc: Jon TURNEY, yselkowitz

Yaakov wrote:

> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=blob;f=3.1-cygwin-includes.patch;h=1444765;hb=HEAD

I think/hope you are going to send it to upstream... :-)


Ciao,
  Angelo.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-01-15 14:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-11 12:55 Another issue with CLANG Angelo Graziosi
2013-01-13 14:31 ` Jon TURNEY
2013-01-13 14:44   ` Angelo Graziosi
2013-01-13 15:21     ` Jon TURNEY
2013-01-14 12:44       ` Angelo Graziosi
2013-01-14 13:43         ` Jon TURNEY
2013-01-15  0:31           ` Yaakov
2013-01-15 14:45           ` Angelo Graziosi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).