From: Paul Eggert <eggert@cs.ucla.edu>
To: shwaresyst <shwaresyst@aol.com>,
eblake@redhat.com, bruno@clisp.org, cbouchar@redhat.com,
bug-m4@gnu.org, libc-alpha@sourceware.org,
austin-group-l@opengroup.org
Subject: Re: SIGSTKSZ is now a run-time variable
Date: Tue, 9 Mar 2021 11:33:38 -0800 [thread overview]
Message-ID: <fc8fa42c-bf08-fffb-c405-ef2b32958889@cs.ucla.edu> (raw)
In-Reply-To: <832918739.1734727.1615306471320@mail.yahoo.com>
On 3/9/21 8:14 AM, shwaresyst via Libc-alpha wrote:
> The question becomes whether glibc is in violation of POSIX for having
> made the change,
I don't see how that would be. Apps must define _SC_SIGSTKSZ_SOURCE or
_GNU_SOURCE to get the new API, which means the apps do not want strict
POSIX conformance anyway.
> or whether POSIX needs to be amended to allow SIGSTKSZ
> to be non-preprocessor-safe and/or non-constant.
That would be a good idea, yes.
> I've now seen reports of several
> projects failing to build when using glibc with this change included.
Yes. I just now checked, and Emacs appears to have this problem so I
installed a patch[1] to Emacs, which should fix it. I'm not surprised
that other packages have similar issues, and would need similar patches.
Gnulib was fixed to avoid this problem in October - before that, Gnulib
didn't even conform to POSIX, because it used SIGSTKSZ in #if. The
Gnulib patch[2] illustrates other portability messes in this area.
[1]
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f97e07ea807cc6d38774a3888a15091b20645ac6
[2]
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f9e2b20a12a230efa30f1d479563ae07d276a94b
next prev parent reply other threads:[~2021-03-09 19:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <832918739.1734727.1615306471320.ref@mail.yahoo.com>
2021-03-09 16:14 ` shwaresyst
2021-03-09 19:33 ` Paul Eggert [this message]
2021-03-09 19:34 ` Eric Blake
2021-03-09 20:12 ` Eric Blake
[not found] <1569476484.1894162.1615325397167.ref@mail.yahoo.com>
2021-03-09 21:29 ` shwaresyst
2021-03-09 23:58 ` H.J. Lu
[not found] <1841269.IEpri3ZHvQ@omega>
2021-03-09 15:23 ` Eric Blake
2021-03-09 15:26 ` Andreas Schwab
2021-03-09 15:48 ` Eric Blake
2021-03-09 19:58 ` Bruno Haible
2021-03-09 21:05 ` H.J. Lu
[not found] ` <20210309211735.GW19922@dragon.sl.home>
2021-03-16 19:46 ` Carol Bouchard
2021-03-26 12:46 ` Carol Bouchard
2021-03-09 15:46 ` Zack Weinberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc8fa42c-bf08-fffb-c405-ef2b32958889@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=austin-group-l@opengroup.org \
--cc=bruno@clisp.org \
--cc=bug-m4@gnu.org \
--cc=cbouchar@redhat.com \
--cc=eblake@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=shwaresyst@aol.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).