[PATCH v2 0/2] MR10577: Fix build with old clang (<13).
When clang < 13 cross-compiles for Windows, it sets _MSC_VER to 1911 (< 1912). The #if/#elif chain in __config checked _MSC_VER < 1912 first, which prevented the elif branch from defining _LIBCPP_DEFER_NEW_TO_VCRUNTIME. This caused placement new/delete to be defined in both vcruntime_new.h and the libc++ <new> header, resulting in redefinition errors. Since Wine always provides aligned allocation operators in vcruntime_new.h, simply remove the _MSC_VER < 1912 cases and always define _LIBCPP_DEFER_NEW_TO_VCRUNTIME when using the Microsoft ABI with vcruntime. Also add fall back to the wmemchr() call or manual loop on clang < 13. -- v2: include: Avoid __builtin_wmemchr with clang < 13. include: Fix _LIBCPP_DEFER_NEW_TO_VCRUNTIME not being set with old clang. https://gitlab.winehq.org/wine/wine/-/merge_requests/10577
From: Vitaly Lipatov <lav@etersoft.ru> When clang < 13 cross-compiles for Windows, it sets _MSC_VER to 1911 (< 1912). The #if/#elif chain in __config checked _MSC_VER < 1912 first, which prevented the elif branch from defining _LIBCPP_DEFER_NEW_TO_VCRUNTIME. This caused placement new/delete to be defined in both vcruntime_new.h and the libc++ <new> header, resulting in redefinition errors. Since Wine always provides aligned allocation operators in vcruntime_new.h, simply remove the _MSC_VER < 1912 cases and always define _LIBCPP_DEFER_NEW_TO_VCRUNTIME when using the Microsoft ABI with vcruntime. --- include/msvcrt/__config | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/include/msvcrt/__config b/include/msvcrt/__config index 78ff1b2ab4e..6585cd5fbde 100644 --- a/include/msvcrt/__config +++ b/include/msvcrt/__config @@ -990,11 +990,8 @@ template <unsigned> struct __static_assert_check {}; #define _DECLARE_C99_LDBL_MATH 1 #endif -// If we are getting operator new from the MSVC CRT, then allocation overloads -// for align_val_t were added in 19.12, aka VS 2017 version 15.3. -#if defined(_LIBCPP_MSVCRT) && defined(_MSC_VER) && _MSC_VER < 1912 -# define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION -#elif defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_NO_VCRUNTIME) +// If we are getting operator new from the MSVC CRT, defer to vcruntime. +#if defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_NO_VCRUNTIME) # define _LIBCPP_DEFER_NEW_TO_VCRUNTIME # if !defined(__cpp_aligned_new) // We're defering to Microsoft's STL to provide aligned new et al. We don't -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10577
From: Vitaly Lipatov <lav@etersoft.ru> Clang < 13 reports __has_feature(cxx_constexpr_string_builtins) as true but does not inline __builtin_wmemchr for Windows targets, generating an external call to wmemchr instead. Since Wine's ucrtbase does not export wmemchr (it is defined as static inline in wchar.h), this causes an undefined symbol error at link time for modules using libc++ (e.g. icu). Fall back to the wmemchr() call or manual loop on clang < 13. --- include/msvcrt/__string | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/msvcrt/__string b/include/msvcrt/__string index b919ff80b67..74328903d1e 100644 --- a/include/msvcrt/__string +++ b/include/msvcrt/__string @@ -374,7 +374,7 @@ char_traits<wchar_t>::find(const char_type* __s, size_t __n, const char_type& __ { if (__n == 0) return nullptr; -#if __has_feature(cxx_constexpr_string_builtins) +#if __has_feature(cxx_constexpr_string_builtins) && __clang_major__ >= 13 return __builtin_wmemchr(__s, __a, __n); #elif _LIBCPP_STD_VER <= 14 return wmemchr(__s, __a, __n); -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10577
On Mon Apr 6 17:58:29 2026 +0000, Vitaly Lipatov wrote:
Unfortunately __has_builtin(__builtin_wmemchr) returns true even on clang 11, where the builtin is not actually inlined for Windows targets — clang emits an external jmp wmemchr call instead: ``` $ echo '#if __has_builtin(__builtin_wmemchr) extern "C" const wchar_t *f(const wchar_t *s, wchar_t c, __SIZE_TYPE__ n) { return __builtin_wmemchr(s, c, n); } #endif' | clang-11 -target x86_64-windows -O2 -S -o - -x c++ - 2>&1 | grep wmemchr jmp wmemchr # TAILCALL ``` On clang 19 the same test produces no external wmemchr reference (the builtin is properly inlined). Since __has_builtin doesn't distinguish these cases, I used __clang_major__ >= 13 instead. In any case, __has_builtin(__builtin_wmemchr) looks more clear than `__has_feature(cxx_constexpr_string_builtins). Will I replace it?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10577#note_135143
On Mon Apr 6 18:03:38 2026 +0000, Vitaly Lipatov wrote:
In any case, __has_builtin(__builtin_wmemchr) looks more clear than `__has_feature(cxx_constexpr_string_builtins). Will I replace it? Yes, I think we could replace it. We should also probably keep GCC as is, that would be something like `(!defined(__clang__) || __clang_major__ > 13)`.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10577#note_135497
participants (3)
-
Jacek Caban (＠jacek) -
Vitaly Lipatov
-
Vitaly Lipatov (＠lav)