From: Paul Eggert <eggert@cs.ucla.edu>
To: Zack Weinberg <zack@owlfolio.org>, Michael Matz <matz@suse.de>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
Aaron Ballman <aaron@aaronballman.com>,
c-std-porting@lists.linux.dev,
Autoconf Development <autoconf@gnu.org>,
gcc@gcc.gnu.org, via cfe-commits <cfe-commits@lists.llvm.org>,
Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Thu, 17 Nov 2022 10:58:52 -0800 [thread overview]
Message-ID: <8101f5cb-082b-8c25-bdf0-7d1cd2531388@cs.ucla.edu> (raw)
In-Reply-To: <d730f354-9b0f-409b-8cdd-82c5d64979e6@app.fastmail.com>
On 2022-11-16 10:59, Zack Weinberg wrote:
> I'm generally in agreement with Rich Felker's argument (inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for linkability of a symbol
So am I. I'm not saying Autoconf should never change here, only that the
change would not be trivial. It would require changing many configure.ac
scripts scattered over many software projects, because Autoconf cannot
be expected to know every signature of every function in every library.
Any such transition could not be done in a week, or a month, or even a
year. I would guess it would take a decade at least. In the meantime if
Clang becomes pickier by default it would be helpful if there were a
well-defined way to shut off Clang's pickiness. If the Clang developers
provide such a way we can use it; if not, Autoconf will just have to do
what it always does, and figure a way out anyway (hey! it could drop
into assembler...).
Things would be simpler if Clang became pickier by default only for
declarations that are not "char foo();" or "char foo(void);". Then,
existing 'configure' scripts would still work.
next prev parent reply other threads:[~2022-11-17 18:58 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 17:16 Zack Weinberg
2022-11-10 17:52 ` Nick Bowler
2022-11-10 17:58 ` Jonathan Wakely
2022-11-10 18:12 ` Jonathan Wakely
2022-11-10 18:44 ` Aaron Ballman
2022-11-12 2:56 ` Zack Weinberg
2022-11-10 18:05 ` Rich Felker
2022-11-10 21:44 ` Florian Weimer
2022-11-12 3:22 ` Zack Weinberg
2022-11-10 18:08 ` Florian Weimer
2022-11-12 3:40 ` Zack Weinberg
2022-11-12 3:43 ` Sam James
2022-11-12 14:27 ` Zack Weinberg
2022-11-12 3:45 ` Joseph Myers
2022-11-12 15:59 ` Wookey
2022-11-12 16:12 ` Zack Weinberg
2022-11-10 18:19 ` Aaron Ballman
2022-11-10 21:05 ` Paul Eggert
2022-11-11 15:11 ` Aaron Ballman
2022-11-13 0:43 ` Paul Eggert
2022-11-14 12:41 ` Aaron Ballman
2022-11-14 18:14 ` Paul Eggert
2022-11-14 18:30 ` Florian Weimer
2022-11-14 18:35 ` Aaron Ballman
2022-11-15 14:50 ` Jonathan Wakely
2022-11-15 19:08 ` Paul Eggert
2022-11-15 19:27 ` Jonathan Wakely
2022-11-15 20:27 ` Paul Eggert
2022-11-15 20:57 ` Aaron Ballman
2022-11-15 23:09 ` Paul Eggert
2022-11-15 23:43 ` Ben Boeckel
2022-11-16 14:26 ` Michael Matz
2022-11-16 14:40 ` Alexander Monakov
2022-11-16 15:01 ` Michael Matz
2022-11-16 15:27 ` Richard Biener
2022-11-16 15:35 ` Sam James
2022-11-16 15:59 ` Michael Matz
2022-11-16 16:20 ` Jonathan Wakely
2022-11-16 16:34 ` Michael Matz
2022-11-16 16:46 ` Jonathan Wakely
2022-11-16 18:17 ` Paul Eggert
2022-11-16 18:40 ` Jeffrey Walton
2022-11-17 18:45 ` Paul Eggert
2022-11-16 18:59 ` Zack Weinberg
2022-11-17 18:58 ` Paul Eggert [this message]
2022-11-17 21:35 ` Bruno Haible
2022-11-17 22:27 ` Paul Eggert
2022-11-17 13:30 ` Michael Matz
2022-11-15 20:36 ` Aaron Ballman
2022-11-15 5:03 ` Sam James
2022-11-15 13:30 ` Zack Weinberg
2022-11-15 13:34 ` Sam James
2022-11-16 0:08 ` Bob Friesenhahn
2022-11-13 0:43 ` Paul Eggert
2022-11-17 13:57 ` Jason Merrill
2022-11-10 20:19 ` Paul Eggert
[not found] ` <d785b19371e8419f5a5817d7cdb429db91614a3a.camel@orlitzky.com>
2022-11-11 3:08 ` Sam James
2022-11-11 3:33 ` Zack Weinberg
2022-11-11 8:40 ` Sam James
2022-11-11 9:02 ` Paul Eggert
2022-11-12 14:09 ` Zack Weinberg
2022-11-11 23:25 ` Sam James
2022-11-12 0:53 ` Paul Eggert
2022-11-12 4:00 ` Sam James
2022-11-11 9:15 ` Sam James
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=8101f5cb-082b-8c25-bdf0-7d1cd2531388@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=aaron@aaronballman.com \
--cc=autoconf@gnu.org \
--cc=bug-gnulib@gnu.org \
--cc=c-std-porting@lists.linux.dev \
--cc=cfe-commits@lists.llvm.org \
--cc=gcc@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=matz@suse.de \
--cc=zack@owlfolio.org \
/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).