[libc++] Always define _LIBCPP_GLIBC_PREREQ - #169405
Merged
philnik777 merged 1 commit intoNov 25, 2025
Merged
Conversation
philnik777
force-pushed
the
unconditionally_define_glibc_prereq
branch
from
November 24, 2025 20:57
e23890a to
6228867
Compare
philnik777
marked this pull request as ready for review
November 25, 2025 11:51
Member
|
@llvm/pr-subscribers-libcxx Author: Nikolas Klauser (philnik777) ChangesAlways defining the macro allows us to simplify the few places where it's used. Full diff: https://github.com/llvm/llvm-project/pull/169405.diff 4 Files Affected:
diff --git a/libcxx/include/__config b/libcxx/include/__config
index 1b27f28f9ddef..26851aad4ca92 100644
--- a/libcxx/include/__config
+++ b/libcxx/include/__config
@@ -678,18 +678,10 @@ typedef __char32_t char32_t;
# endif // _LIBCPP_HAS_THREAD_API
# endif // _LIBCPP_HAS_THREADS
-# if _LIBCPP_HAS_THREAD_API_PTHREAD
-# if defined(__ANDROID__) && __ANDROID_API__ >= 30
-# define _LIBCPP_HAS_COND_CLOCKWAIT 1
-# elif defined(_LIBCPP_GLIBC_PREREQ)
-# if _LIBCPP_GLIBC_PREREQ(2, 30)
-# define _LIBCPP_HAS_COND_CLOCKWAIT 1
-# else
-# define _LIBCPP_HAS_COND_CLOCKWAIT 0
-# endif
-# else
-# define _LIBCPP_HAS_COND_CLOCKWAIT 0
-# endif
+# if !_LIBCPP_HAS_THREAD_API_PTHREAD
+# define _LIBCPP_HAS_COND_CLOCKWAIT 0
+# elif (defined(__ANDROID__) && __ANDROID_API__ >= 30) || _LIBCPP_GLIBC_PREREQ(2, 30)
+# define _LIBCPP_HAS_COND_CLOCKWAIT 1
# else
# define _LIBCPP_HAS_COND_CLOCKWAIT 0
# endif
@@ -855,12 +847,8 @@ typedef __char32_t char32_t;
// the latter depends on internal GNU libc details that are not appropriate
// to depend on here, so any declarations present when __cpp_char8_t is not
// defined are ignored.
-# if defined(_LIBCPP_GLIBC_PREREQ)
-# if _LIBCPP_GLIBC_PREREQ(2, 36) && defined(__cpp_char8_t)
-# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 1
-# else
-# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 0
-# endif
+# if _LIBCPP_GLIBC_PREREQ(2, 36) && defined(__cpp_char8_t)
+# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 1
# else
# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 0
# endif
diff --git a/libcxx/include/__configuration/platform.h b/libcxx/include/__configuration/platform.h
index f3c199dee172b..88bba5473c608 100644
--- a/libcxx/include/__configuration/platform.h
+++ b/libcxx/include/__configuration/platform.h
@@ -31,15 +31,15 @@
#endif
// Need to detect which libc we're using if we're on Linux.
-#if defined(__linux__) || defined(__AMDGPU__) || defined(__NVPTX__)
-# if __has_include(<features.h>)
-# include <features.h>
-# if defined(__GLIBC_PREREQ)
-# define _LIBCPP_GLIBC_PREREQ(a, b) __GLIBC_PREREQ(a, b)
-# else
-# define _LIBCPP_GLIBC_PREREQ(a, b) 0
-# endif // defined(__GLIBC_PREREQ)
-# endif
+#if (defined(__linux__) || defined(__AMDGPU__) || defined(__NVPTX__)) && __has_include(<features.h>)
+# include <features.h>
+# if defined(__GLIBC_PREREQ)
+# define _LIBCPP_GLIBC_PREREQ(a, b) __GLIBC_PREREQ(a, b)
+# else
+# define _LIBCPP_GLIBC_PREREQ(a, b) 0
+# endif // defined(__GLIBC_PREREQ)
+#else
+# define _LIBCPP_GLIBC_PREREQ(a, b) 0
#endif
// This is required in order for _NEWLIB_VERSION to be defined in places where we use it.
diff --git a/libcxx/include/__random/binomial_distribution.h b/libcxx/include/__random/binomial_distribution.h
index bada8cfdd74a3..0712e4ef4a4f6 100644
--- a/libcxx/include/__random/binomial_distribution.h
+++ b/libcxx/include/__random/binomial_distribution.h
@@ -98,13 +98,7 @@ class binomial_distribution {
};
// Some libc declares the math functions to be `noexcept`.
-#if defined(_LIBCPP_GLIBC_PREREQ)
-# if _LIBCPP_GLIBC_PREREQ(2, 8)
-# define _LIBCPP_LGAMMA_R_NOEXCEPT _NOEXCEPT
-# else
-# define _LIBCPP_LGAMMA_R_NOEXCEPT
-# endif
-#elif defined(__LLVM_LIBC__)
+#if _LIBCPP_GLIBC_PREREQ(2, 8) || defined(__LLVM_LIBC__)
# define _LIBCPP_LGAMMA_R_NOEXCEPT _NOEXCEPT
#else
# define _LIBCPP_LGAMMA_R_NOEXCEPT
diff --git a/libcxx/src/filesystem/operations.cpp b/libcxx/src/filesystem/operations.cpp
index b71f94a89d6df..745db87ce3736 100644
--- a/libcxx/src/filesystem/operations.cpp
+++ b/libcxx/src/filesystem/operations.cpp
@@ -41,17 +41,10 @@
#include <time.h>
// since Linux 4.5 and FreeBSD 13, but the Linux libc wrapper is only provided by glibc >= 2.27 and musl
-#if defined(__linux__)
-# if defined(_LIBCPP_GLIBC_PREREQ)
-# if _LIBCPP_GLIBC_PREREQ(2, 27)
-# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE
-# endif
-# elif _LIBCPP_HAS_MUSL_LIBC
-# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE
-# endif
-#elif defined(__FreeBSD__)
+#if _LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__)
# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE
#endif
+
#if __has_include(<sys/sendfile.h>)
# include <sys/sendfile.h>
# define _LIBCPP_FILESYSTEM_USE_SENDFILE
|
simpal01
added a commit
to simpal01/arm-toolchain
that referenced
this pull request
Nov 26, 2025
…onfig Upstream LLVM introduced changes in libcxx/include/__config that overlap with the area modified by our patch 0001-Define-_LIBCPP_HAS_C8RTOMB_MBRTOC8.patch. As a result, the patch no longer applied cleanly during git am. This PR updates and rebases the patch to reflect the upstream modifications while preserving its original functionality. No functional change beyond re-aligning with upstream is intended. Upstream change: llvm/llvm-project#169405
simpal01
added a commit
to arm/arm-toolchain
that referenced
this pull request
Nov 26, 2025
…onfig (#625) Upstream LLVM introduced changes in libcxx/include/__config that overlap with the area modified by our patch 0001-Define-_LIBCPP_HAS_C8RTOMB_MBRTOC8.patch. As a result, the patch no longer applied cleanly during git am. This PR updates and rebases the patch to reflect the upstream modifications while preserving its original functionality. No functional change beyond re-aligning with upstream is intended. Upstream change: llvm/llvm-project#169405
|
@ philnik777 this pullrequest broke compiling libcxx for wasm32-wasip1 target, I have linked the issue under mentioned. Can you please be so kind and have a look at it? |
aheejin
added a commit
to aheejin/emscripten
that referenced
this pull request
Jul 28, 2026
llvm/llvm-project#169405 has this: ```diff --- a/libcxx/src/filesystem/operations.cpp +++ b/libcxx/src/filesystem/operations.cpp @@ -41,17 +41,10 @@ #include <time.h> // since Linux 4.5 and FreeBSD 13, but the Linux libc wrapper is only provided by glibc >= 2.27 and musl -#if defined(__linux__) -# if defined(_LIBCPP_GLIBC_PREREQ) -# if _LIBCPP_GLIBC_PREREQ(2, 27) -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -# elif _LIBCPP_HAS_MUSL_LIBC -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -#elif defined(__FreeBSD__) +#if _LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__) # define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE #endif + #if __has_include(<sys/sendfile.h>) # include <sys/sendfile.h> # define _LIBCPP_FILESYSTEM_USE_SENDFILE ``` Before the PR, because we didn't define `__linux__`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was not defined. But after it `#if defined(__linux__)` check was gone, and because we defined `_LIBCPP_HAS_MUSL_LIBC`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was defined as well. After this PR, we started to have `error: undefined symbol: copy_file_range` error on `core*.test_dylink_exceptions_try_catch_6_*` tests. --- This commit fixes the linker error by wiring up `SYS_copy_file_range` and provides a stub implementation returning `-ENOSYS` for both legacy JS syscalls and WASMFS. This allows `copy_file_range.c` from musl to be compiled into the system library. The libcxx implementation falls back to other mechanisms when receiving `ENOSYS`.
aheejin
added a commit
to aheejin/emscripten
that referenced
this pull request
Jul 28, 2026
llvm/llvm-project#169405 has this: ```diff --- a/libcxx/src/filesystem/operations.cpp +++ b/libcxx/src/filesystem/operations.cpp @@ -41,17 +41,10 @@ #include <time.h> // since Linux 4.5 and FreeBSD 13, but the Linux libc wrapper is only provided by glibc >= 2.27 and musl -#if defined(__linux__) -# if defined(_LIBCPP_GLIBC_PREREQ) -# if _LIBCPP_GLIBC_PREREQ(2, 27) -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -# elif _LIBCPP_HAS_MUSL_LIBC -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -#elif defined(__FreeBSD__) +#if _LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__) # define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE #endif + #if __has_include(<sys/sendfile.h>) # include <sys/sendfile.h> # define _LIBCPP_FILESYSTEM_USE_SENDFILE ``` Before the PR, because we didn't define `__linux__`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was not defined. But after it `#if defined(__linux__)` check was gone, and because we defined `_LIBCPP_HAS_MUSL_LIBC`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was defined as well. After this PR, we started to have `error: undefined symbol: copy_file_range` error on `core*.test_dylink_exceptions_try_catch_6_*` tests. --- This commit fixes the linker error by wiring up `SYS_copy_file_range` and provides a stub implementation returning `-ENOSYS` for both legacy JS syscalls and WASMFS. This allows `copy_file_range.c` from musl to be compiled into the system library. The libcxx implementation falls back to other mechanisms when receiving `ENOSYS`.
aheejin
added a commit
to aheejin/emscripten
that referenced
this pull request
Jul 29, 2026
llvm/llvm-project#169405 has this: ```diff --- a/libcxx/src/filesystem/operations.cpp +++ b/libcxx/src/filesystem/operations.cpp @@ -41,17 +41,10 @@ #include <time.h> // since Linux 4.5 and FreeBSD 13, but the Linux libc wrapper is only provided by glibc >= 2.27 and musl -#if defined(__linux__) -# if defined(_LIBCPP_GLIBC_PREREQ) -# if _LIBCPP_GLIBC_PREREQ(2, 27) -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -# elif _LIBCPP_HAS_MUSL_LIBC -# define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE -# endif -#elif defined(__FreeBSD__) +#if _LIBCPP_GLIBC_PREREQ(2, 27) || _LIBCPP_HAS_MUSL_LIBC || defined(__FreeBSD__) # define _LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE #endif + #if __has_include(<sys/sendfile.h>) # include <sys/sendfile.h> # define _LIBCPP_FILESYSTEM_USE_SENDFILE ``` Before the PR, because we didn't define `__linux__`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was not defined. But after it `#if defined(__linux__)` check was gone, and because we defined `_LIBCPP_HAS_MUSL_LIBC`, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was defined as well. After this PR, we started to have `error: undefined symbol: copy_file_range` error on `core*.test_dylink_exceptions_try_catch_6_*` tests. --- This commit adds `!defined(__EMSCRIPTEN__)` clause at the end to make `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` undefined for Emscripten, as was before this update.
aheejin
added a commit
to emscripten-core/emscripten
that referenced
this pull request
Jul 29, 2026
This updates libcxx and libcxxabi from 21.1.8 to LLVM 22.1.8: https://github.com/llvm/llvm-project/releases/tag/llvmorg-22.1.8 Additional changes: (More detailed descriptions are in the commit messages) - Don't copy llvm-libc files in `update_libcxx.py`: e7af49c, e81407b In `update_libcxx.py`, we don't copy llvm-libc files that libcxx depend on anymore, because we copy those files in `update_llvm_libc.py` too. We just assume llvm-libc has been updated to the same version before doing update, and I wrote that in the comments. - Define `_LIBCPP_ASSERTION_SEMANTIC_DEFAULT` in `__config_site`: b119c87 llvm/llvm-project#167636 forces us to define `_LIBCPP_ASSERTION_SEMANTIC_DEFAULT`. This defines it to follow the hardening mode. - Undefine `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE`: e9f7296 After llvm/llvm-project#169405, `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` was defined, which caused Emscripten to use `copy_file_range`. This commit adds `!defined(__EMSCRIPTEN__)` clause at the end to make `_LIBCPP_FILESYSTEM_USE_COPY_FILE_RANGE` undefined for Emscripten, as was before this update. - Make `__cxa_thread_atexit` available for Emscripten: 638d0e1 llvm/llvm-project#116261 wrapped `__cxa_thread_atexit` with `#if defined(__linux__) || defined(__Fuchsia__)`, which caused it to be undefined in Emscripten. This adds `defined(__EMSCRIPTEN__)` to make it available again. - Increase size expectations of `test_malloc_size*`: c818aa2 This increase seems to be mainly due to the changes of implementation of `std::num_get` in `libcxx/include/__locale_dir/num.h` in llvm/llvm-project#121795. Note that we had a similar size increase due to changes in `std::num_put` in llvm/llvm-project#133572 in LLVM 21 update (#26058). - Create `module.modulemap` from `module.modulemap.in`: be1f0a7 libcxx used to have `module.modulemap`, but since LLVM 21, it was changed to `module.modulemap.in` in llvm/llvm-project#134699. Rather than we copy this manually in each update, this makes `update_libcxx.py` create `module.modulemap` from `module.modulemap.in` automaticaly. - Copy `default_assertion_handler.in` to `__assertion_handler`: 547432f Since LLVM 18, llvm/llvm-project#77883 started to provide a default assertion handler and a way to override it. We have been using the default handler ever since. Rather than manually copying it in each release, this automates the copying of the file in `update_libcxx.py`.
Contributor
|
@philnik777 ping. This breaks the libcxx build for wasm32-wasip1: |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Always defining the macro allows us to simplify the few places where it's used.