[llvm-bugs] [Bug 26365] New: Can no longer build with mingw-w64 using win32 threads

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jan 28 17:51:08 PST 2016


https://llvm.org/bugs/show_bug.cgi?id=26365

            Bug ID: 26365
           Summary: Can no longer build with mingw-w64 using win32 threads
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The mingw-w64 toolchains generally come with two different threading models.
One is straight bindings to the win32 threading APIs, and the other is a
pthread threading model (with a pthreads-like interface). Over in Rust-land we
tend to prefer the win32 toolchain because the generated binaries won't have a
dependency on libpthread.dll.

With LLVM 3.8, however, the mingw-w64 toolchains with the win32 threading model
can no longer build LLVM. This is unfortunately because the `std::thread` type
only exists in the pthreads toolchain, not in the win32 one.

We'd love to stick with the win32 toolchain if possible (fewer runtime
dependencies of the compiler), so I was wondering a few things:

* Has anyone else run into this yet? If so, sorry for the noise!
* Would it be possible to support the win32 mingw-w64 toolchains? Unfortunately
the only way I know of to do this would be to not use `std::thread` (which I
suspect is quite nice to use...)
* Would it be possible to #define away the support that requires `std::thread`?
We probably don't need this class and/or the support it enables in Rust, so if
we could just not build this part that'd also work for us!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160129/61101e17/attachment-0001.html>


More information about the llvm-bugs mailing list