[cfe-dev] Building with mingw64 on Windows issue

Maarten Verhage via cfe-dev cfe-dev at lists.llvm.org
Sun Dec 9 09:39:23 PST 2018


Hi Martin,

Ok, good progress now. Your suggestion to remove the 
DCMAKE_SYSTEM_NAME=Windows line did it. Now I don't have that NATIVE folder 
and neither that "No rule to make target" error. Thank a lot for that. I 
could have spend hours and a lot of frustration until I finally try to 
remove that line.

Now it seems to build to the end. about 4GB on the T: drive. A lib folder 
full of LLVM and clang libraries.And a bin folder full of executables.

In the process there are some warnings like:
1)
C:\dev\llvm\lib\IR\Core.cpp: In function 'void 
LLVMContextSetDiagnosticHandler(LLVMContextRef, LLVMDiagnosticHandler, 
void*)':
C:\dev\llvm\lib\IR\Core.cpp:91:18: warning: cast between incompatible 
function types from 'LLVMDiagnosticHandler' {aka 'void 
(*)(LLVMOpaqueDiagnosticInfo*, void*)'} to 
'llvm::DiagnosticHandler::DiagnosticHandlerTy' {aka 'void (*)(const 
llvm::DiagnosticInfo&, void*)'} [-Wcast-function-type]
           Handler),

2)
C:/dev/llvm/include/llvm/ADT/StringRef.h:302:37: warning: 'void* 
memchr(const void*, int, size_t)' specified size 18446744073709551615 
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

3)
C:\dev\llvm\tools\clang\tools\c-index-test\c-index-test.c:1018:62: warning: 
unknown conversion type character 'l' in format [-Wformat=]
               printf(" [Template arg %d: kind: %d, intval: %lld]",

For the last one I thought I needed to set CMAKE_C_FLAGS to -std=c99 but 
when building again I do get the same warnings on that c file.

I realize building took some time so I set LLVM_TARGETS_TO_BUILD just to X86 
and on the mingw32-make invocation to -j4 for the 4 cores I have.

> Hi Maarten,
>
> On Sat, 8 Dec 2018, Maarten Verhage wrote:
>
>> Yes, good idea. Going for x86_64-8.1.0-release-posix-seh-rt_v6-rev0! Also 
>> I
>> did realize I made a mistake in my windows command prompt script. The 
>> reason
>> it wasn't able to find std::mutex was that I didn't specify the include
>> folders for the gcc includes. The header file mutex certainly is present 
>> in
>> the mingw64 folder tree. It is also present in the win32 threads variant 
>> so
>> I might try that too, when I see the posix variant is building LLVM/clang
>> correctly.
>
> That's rather strange. Normally you don't need to manually specify the 
> include directories but they are implicit when you invoke GCC, but they 
> are implicifly found when you invoke the compiler. I'm fairly sure the 
> prebuilt GCC versions from mingw installers work that way.
>
You're right. I figured the specification of the include folders are 
redundant. There is another reason why in the mingw win32 threads variant 
there is an issue about utilizing the header mutex. But in the posix variant 
it just builds w/o that specification. However I'm a bit curious how cmake 
is able to find the header files within the mingw source tree.

As my goal is to have an LLVM/clang toolchain with standard Windows API 
threads what would be the next step for me?
Or do I need to do some tests to see if my clang toolchain is stable?

Also I'm not quite sure at which moment I need to have which toolchain bin 
folder in my PATH environment variable. My guess is to take the mingw64 bin 
folder out of my path, set the bin folder of LLVM there and build libcxxabi 
with clang and have  D_LIBCPP_BUILDING_LIBRARY and 
_LIBCPP_HAS_THREAD_API_WIN32 be set. Should the library be placed in the 
build lib folder along with the libclangxxx.a and libLLVMxxx.a files?

Thanks a lot you're really helping me.

Best regards,
Maarten 



More information about the cfe-dev mailing list