# $(1) is the target triple
-ifeq ($$(CFG_WINDOWSY_$(1)), 1)
- # This isn't necessarily a desired option, but it's harmless and works around
- # what appears to be a mingw-w64 bug.
+ifeq ($$(CFG_WINDOWSY_$(1)),1)
+ # A bit of history here, this used to be --enable-lazy-lock added in #14006
+ # which was filed with jemalloc in jemalloc/jemalloc#83 which was also
+ # reported to MinGW: http://sourceforge.net/p/mingw-w64/bugs/395/
+ #
+ # When updating jemalloc to 4.0, however, it was found that binaries would
+ # exit with the status code STATUS_RESOURCE_NOT_OWNED indicating that a thread
+ # was unlocking a mutex it never locked. Disabling this "lazy lock" option
+ # seems to fix the issue, but it was enabled by default for MinGW targets in
+ # 13473c7 for jemalloc.
+ #
+ # As a result of all that, force disabling lazy lock on Windows, and after
+ # reading some code it at least *appears* that the initialization of mutexes
+ # is otherwise ok in jemalloc, so shouldn't cause problems hopefully...
#
- # https://sourceforge.net/p/mingw-w64/bugs/395/
- JEMALLOC_ARGS_$(1) := --enable-lazy-lock
+ # tl;dr: make windows behave like other platforms by disabling lazy locking,
+ # but requires passing an option due to a historical default with
+ # jemalloc.
+ JEMALLOC_ARGS_$(1) := --disable-lazy-lock
else ifeq ($(OSTYPE_$(1)), apple-ios)
JEMALLOC_ARGS_$(1) := --disable-tls
else ifeq ($(findstring android, $(OSTYPE_$(1))), android)
}).and_then(|root| {
fs::read_dir(Path::new(&root).join("Lib")).ok()
}).and_then(|readdir| {
- let mut dirs: Vec<_> = readdir.filter_map(|dir| dir.ok())
- .map(|dir| dir.path()).collect();
+ let mut dirs: Vec<_> = readdir.filter_map(|dir| {
+ dir.ok()
+ }).map(|dir| {
+ dir.path()
+ }).filter(|dir| {
+ dir.components().last().and_then(|c| {
+ c.as_os_str().to_str()
+ }).map(|c| c.starts_with("10.")).unwrap_or(false)
+ }).collect();
dirs.sort();
dirs.pop()
})