On Thu, 25 Feb 2021 at 10:52, <notifications@xxxxxxxxxxxxxxxxx> wrote:
Notification time stamped 2021-02-25 10:17:40 UTC
>From a9bc8b5947d10f13996e6e5d7280e5860473bbd4 Mon Sep 17 00:00:00 2001
From: Yaakov Selkowitz <yselkowi@xxxxxxxxxx>
Date: Feb 25 2021 03:05:37 +0000
Subject: Fix build with glibc 2.34
https://github.com/ColinIanKing/stress-ng/issues/107
---
diff --git a/stress-ng-0.12.03-sigstksz.patch b/stress-ng-0.12.03-sigstksz.patch
new file mode 100644
index 0000000..b05c935
--- /dev/null
+++ b/stress-ng-0.12.03-sigstksz.patch
@@ -0,0 +1,661 @@
+From 7c4f74761089177127c2cfe6685b7886aa231885 Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@xxxxxxxxxxxxx>
+Date: Thu, 25 Feb 2021 00:33:17 +0000
+Subject: [PATCH] stack handling: use _SC_SIGSTKSZ and _SC_MINSIGSTKSZ
+
+New versions of glibc will define SIGSTKSZ and MINSTKSZ
+on the sysconf values for _SC_SIGSTKSZ and _SC_MINSIGSTKSZ
+respectively. Define two helper functions to determine the
+stack sizes by trying to use cached sysconf values, fetching
+and caching the sysconf values or falling back to the
+traditional SIGSTKSZ or MINSTKSZ defined values, or hard
+coded 8K limits if all else fails.
+
+Define STRESS_SIGSTKSZ and STRESS_MINSTKSZ that call the
+helper functions and hide the details. Since these sizes
+are dynamic, replace all statically allocated and stack
+allocated alternative stacks with mmap'd versions and add
+in allocation failure error handling.
+
+Finally remove the MLOCKED_DATA macros now that the mlocked
+alt stacks are no longer used.
+
+Signed-off-by: Colin Ian King <colin.king@xxxxxxxxxxxxx>
+---
+ core-helper.c | 85 +++++++++++++++++++++++++++++++++----------
+ stress-bad-altstack.c | 39 ++++++++++----------
+ stress-context.c | 19 +++++++---
+ stress-ng.c | 3 --
+ stress-ng.h | 10 ++++-
+ stress-rlimit.c | 15 +++++++-
+ stress-stack.c | 18 ++++-----
+ stress-stackmmap.c | 70 ++++++++++++++++++++---------------
+ stress-vforkmany.c | 14 +++++--
+ 9 files changed, 180 insertions(+), 93 deletions(-)
Hmm .. looks like there will probably be maaaany packages affected by this issue because of the recent glibc changes.
The same is with ocaml https://github.com/ocaml/ocaml/issues/10250
Is it not kind of a mistake in case of glibc to introduce such changes? (just asking to only have confirmation that it was not actual mistake and not to start another flame)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
