[cfe-dev] [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

[Mueller-Roemer, Johannes Sebastian]

You don't have to distribute libwinpthread.dll with your application. Considering that libwinpthread is approx. 50 KiB, that's not much of a reason. "Classic" MinGW doesn't have it AFAIK, but who uses that instead of MinGW-w64 nowadays?

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Yaron Keren
Sent: Wednesday, September 24, 2014 15:32
To: Óscar Fuentes
Cc: lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Developers; LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Hi Oscar,

The question is should llvm start using <thread> and <mutex> when mingw+win32 threads does not support these.

What is the reason to use mingw+win32 threads instead of mingw+pthreads which does support the above?

Yaron


2014-09-24 15:47 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es<mailto:ofv at wanadoo.es>>:
Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> writes:

> AKA: MinGW + win32threads is holding LLVM (and all of its subprojects)
> back. We need to stop supporting this host platform.
>
> I'm aware of essentially 2 reasonably important use cases for supporting
> MinGW + win32threads:

I suppose that you are talking about MinGW (www.mingw.org<http://www.mingw.org>) all along
and not about MinGW-w64 (www.mingw-w64.org<http://www.mingw-w64.org>) which supports the features
you are missing.

> 1) Sane host toolchain on Windows that doesn't require downloading MSVC.
> (I'm dubious about the value of this one...)

Oh, well. You are talking about "everything that is not MSVC++". Ok.

> 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or
> other host) box.

I have no idea how cross-compiling from other OS can solve shortcomings
on the *runtime* libraries of a toolchain.

[snip]

> I *really* don't want to spend lots of time going
> there because it seems like a low-value platform, but we can.

Thanks, I knew that you consider MinGW* "low-value" all along. MinGW-w64
is well ahead of MSVC++ on C++ language and library support, and it is
very likely that it will remain that way, but you take every chance to
bad-mouth it to promote MSVC++ support on LLVM/Clang.

[snip]

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140924/6d892a4e/attachment.html>