[LLVMdev] [Patch] Build failure on Windows+MinGW (GCC and Clang)

[Ruben Van Boxem]

When building LLVM/Clang, I get the following build failure:

[  4%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.obj
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:48:17: error: redefinition of '_IMAGEHLP_LINE64'
 typedef struct _IMAGEHLP_LINE64 {
                ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:475:18: note: previous definition is here
  typedef struct _IMAGEHLP_LINE64 {
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:56:17: error: redefinition of '_IMAGEHLP_SYMBOL64'
 typedef struct _IMAGEHLP_SYMBOL64 {
                ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:353:18: note: previous definition is here
  typedef struct _IMAGEHLP_SYMBOL64 {
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:65:17: error: redefinition of '_tagADDRESS64'
 typedef struct _tagADDRESS64 {
                ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:154:18: note: previous definition is here
  typedef struct _tagADDRESS64 {
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:71:17: error: redefinition of '_KDHELP64'
 typedef struct _KDHELP64 {
                ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:183:18: note: previous definition is here
  typedef struct _KDHELP64 {
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:86:17: error: redefinition of '_tagSTACKFRAME64'
 typedef struct _tagSTACKFRAME64 {
                ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:231:18: note: previous definition is here
  typedef struct _tagSTACKFRAME64 {
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:118:22: error: redefinition of 'StackWalk64' as different kind of symbol
static fpStackWalk64 StackWalk64;
                     ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:269:20: note: previous definition is here
  WINBOOL IMAGEAPI StackWalk64(DWORD MachineType,HANDLE hProcess,HANDLE hThread,LPSTACKFRAME64 StackFrame,PVOID ContextRecord,PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,PGET_MODULE_BASE_ROUTINE64
                   ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:121:29: error: redefinition of 'SymGetModuleBase64' as different kind of symbol
static fpSymGetModuleBase64 SymGetModuleBase64;
                            ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:728:20: note: previous definition is here
  DWORD64 IMAGEAPI SymGetModuleBase64(HANDLE hProcess,DWORD64 qwAddr);
                   ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:125:30: error: redefinition of 'SymGetSymFromAddr64' as different kind of symbol
static fpSymGetSymFromAddr64 SymGetSymFromAddr64;
                             ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:1018:20: note: previous definition is here
  WINBOOL IMAGEAPI SymGetSymFromAddr64(HANDLE hProcess,DWORD64 qwAddr,PDWORD64 pdwDisplacement,PIMAGEHLP_SYMBOL64 Symbol);
                   ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:129:31: error: redefinition of 'SymGetLineFromAddr64' as different kind of symbol
static fpSymGetLineFromAddr64 SymGetLineFromAddr64;
                              ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:777:20: note: previous definition is here
  WINBOOL IMAGEAPI SymGetLineFromAddr64(HANDLE hProcess,DWORD64 qwAddr,PDWORD pdwDisplacement,PIMAGEHLP_LINE64 Line64);
                   ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:132:35: error: redefinition of 'SymFunctionTableAccess64' as different kind of symbol
static fpSymFunctionTableAccess64 SymFunctionTableAccess64;
                                  ^
M:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include\psdk_inc/_dbg_common.h:709:18: note: previous definition is here
  PVOID IMAGEAPI SymFunctionTableAccess64(HANDLE hProcess,DWORD64 AddrBase);
                 ^
In file included from M:\Development\Source\LLVM\lib\Support\Signals.cpp:33:
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:137:17: error: non-object type 'WINBOOL (DWORD, HANDLE, HANDLE, LPSTACKFRAME64, PVOID, PREAD_PROCESS_MEMORY_ROUTINE64, PFUNCTION_TABLE_ACCESS_ROUTINE64, PGET_MODULE_BASE_ROUTINE64, PTRANSLATE_ADDRESS_ROUTINE64)' is not assignable
    StackWalk64 = (fpStackWalk64)
    ~~~~~~~~~~~ ^
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:139:24: error: non-object type 'DWORD64 (HANDLE, DWORD64)' is not assignable
    SymGetModuleBase64 = (fpSymGetModuleBase64)
    ~~~~~~~~~~~~~~~~~~ ^
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:141:25: error: non-object type 'WINBOOL (HANDLE, DWORD64, PDWORD64, PIMAGEHLP_SYMBOL64)' is not assignable
    SymGetSymFromAddr64 = (fpSymGetSymFromAddr64)
    ~~~~~~~~~~~~~~~~~~~ ^
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:143:26: error: non-object type 'WINBOOL (HANDLE, DWORD64, PDWORD, PIMAGEHLP_LINE64)' is not assignable
    SymGetLineFromAddr64 = (fpSymGetLineFromAddr64)
    ~~~~~~~~~~~~~~~~~~~~ ^
M:\Development\Source\LLVM\lib\Support/Windows/Signals.inc:145:30: error: non-object type 'PVOID (HANDLE, DWORD64)' is not assignable
    SymFunctionTableAccess64 = (fpSymFunctionTableAccess64)
    ~~~~~~~~~~~~~~~~~~~~~~~~ ^
15 errors generated.
mingw32-make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.obj] Error 1

MinGW-w64 provides the necessary typedefs and declarations. I adjusted the ifdef's to include a check for a the MinGW-w64-specific symbol of choice to differentiate mingw.org vs mingw-w64. Tested on i686-w64-mingw32 and x86_64-w64-mingw32.

Please comment or apply. (I am not subscribed to llvm-dev, sorry :-/)

Ruben

[Aaron Ballman]

On Thu, Oct 6, 2011 at 2:00 PM, Ruben Van Boxem
<vanboxe...@gmail.com> wrote:
> When building LLVM/Clang, I get the following build failure:
>

> MinGW-w64 provides the necessary typedefs and declarations. I adjusted the
> ifdef's to include a check for a the MinGW-w64-specific symbol of choice to
> differentiate mingw.org vs mingw-w64. Tested on i686-w64-mingw32 and
> x86_64-w64-mingw32.
>
> Please comment or apply. (I am not subscribed to llvm-dev, sorry :-/)

I believe that would be my fault -- sorry about that. MinGW 64
appears to have the proper support already built in, but 32-bit does
not. This patch looks good to me, thanks for the help!

~Aaron
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Ruben Van Boxem]

2011/10/6 Aaron Ballman <aa...@aaronballman.com>

On Thu, Oct 6, 2011 at 2:00 PM, Ruben Van Boxem
<vanboxe...@gmail.com> wrote:
> When building LLVM/Clang, I get the following build failure:
>

> MinGW-w64 provides the necessary typedefs and declarations. I adjusted the
> ifdef's to include a check for a the MinGW-w64-specific symbol of choice to
> differentiate mingw.org vs mingw-w64. Tested on i686-w64-mingw32 and
> x86_64-w64-mingw32.
>
> Please comment or apply. (I am not subscribed to llvm-dev, sorry :-/)

I believe that would be my fault -- sorry about that.  MinGW 64
appears to have the proper support already built in, but 32-bit does
not.  This patch looks good to me, thanks for the help!

You're welcome! Please remember that MinGW-w64 does not mean it is 64-bit. It provides both 32- and 64-bit headers/libs. The "w64" in the name was originally because that was the project's principal goal, among extending the API completeness and compatibility with MSVC. Just so that I don't find any MinGW-w64/.org 64-bit misconceptions in LLVM code later ;-) It's an understandable mistake (and the name doesn't help at all :-/)

Ruben

~Aaron

[Aaron Ballman]

You learn something new every day... I had no idea this existed (I've
always been a Visual Studio person, and rarely use MinGW of any
variety). Now I know I've got something else to test next time. :-)

[Ruben Van Boxem]

2011/10/6 Aaron Ballman <aa...@aaronballman.com>

On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem
<vanboxe...@gmail.com> wrote:
> You're welcome! Please remember that MinGW-w64 does not mean it is 64-bit.
> It provides both 32- and 64-bit headers/libs. The "w64" in the name was
> originally because that was the project's principal goal, among extending
> the API completeness and compatibility with MSVC. Just so that I don't find
> any MinGW-w64/.org 64-bit misconceptions in LLVM code later ;-) It's an
> understandable mistake (and the name doesn't help at all :-/)

You learn something new every day... I had no idea this existed (I've
always been a Visual Studio person, and rarely use MinGW of any
variety).  Now I know I've got something else to test next time.  :-)

Ping.

It seems this problem is still present on LLVM trunk (and thus 3.0-rc1). This prevents building a 64-bit Windows LLVM with MinGW-w64.

Ruben
 

~Aaron

[Aaron Ballman]

On Thu, Oct 20, 2011 at 12:44 PM, Ruben Van Boxem

<vanboxe...@gmail.com> wrote:
> 2011/10/6 Aaron Ballman <aa...@aaronballman.com>
>>
>> On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem
>> <vanboxe...@gmail.com> wrote:
>> > You're welcome! Please remember that MinGW-w64 does not mean it is
>> > 64-bit.
>> > It provides both 32- and 64-bit headers/libs. The "w64" in the name was
>> > originally because that was the project's principal goal, among
>> > extending
>> > the API completeness and compatibility with MSVC. Just so that I don't
>> > find
>> > any MinGW-w64/.org 64-bit misconceptions in LLVM code later ;-) It's an
>> > understandable mistake (and the name doesn't help at all :-/)
>>
>> You learn something new every day... I had no idea this existed (I've
>> always been a Visual Studio person, and rarely use MinGW of any
>> variety).  Now I know I've got something else to test next time.  :-)
>
> Ping.
>
> It seems this problem is still present on LLVM trunk (and thus 3.0-rc1).
> This prevents building a 64-bit Windows LLVM with MinGW-w64.
>

I think the patch looks good -- thank you for keeping on top of it!

[Anton Korobeynikov]

Hi Ruben,

> It seems this problem is still present on LLVM trunk (and thus 3.0-rc1).
> This prevents building a 64-bit Windows LLVM with MinGW-w64.

Looks ok, please apply!

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

[Ruben Van Boxem]

Op 20 okt. 2011 20:23 schreef "Anton Korobeynikov" <an...@korobeynikov.info> het volgende:

>
> Hi Ruben,
>
> > It seems this problem is still present on LLVM trunk (and thus 3.0-rc1).
> > This prevents building a 64-bit Windows LLVM with MinGW-w64.
> Looks ok, please apply!

I don't have commit access, should have said so... Please commit for me, thanks!

Ruben

[Anton Korobeynikov]

Hi Ruben,

> I don't have commit access, should have said so... Please commit for me,
> thanks!

Committed as r142646, thanks!

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University