Rich Felker <dalias@xxxxxxxx> writes: > On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: >> The biggest remaining (potential) problem, that I’m aware of, is that >> AC_CHECK_FUNC unconditionally declares the function we’re probing for >> as ‘char NAME (void)’, and asks the compiler to call it with no >> arguments, regardless of what its prototype actually is. … > Thanks for bringing this up. It is very important and I am very much > in favor of making these changes and doing it in a way that existing > broken and unmaintained software can be made to work just by > re-generating configure scripts with up-to-date autoconf, even if that > means hard-coding a list of headers needed to get the right > declarations and automatically pulling them in. Right. In principle, I think AC_CHECK_FUNCS([symbol]), where ‘symbol’ is in either ISO C or in XSI, could be made to do a check of the form you suggest at the end of https://ewontfix.com/13/ #include <stdlib.h> #include <locale.h> int main() { double (*p)(const char *, char **, locale_t) = strtod_l; } It’s “just” a matter of compiling that big list of headers and expected function signatures. I’d also want to do something to ensure that this assignment is not optimized out, so the linker has to process an undefined reference to the symbol. For symbols that are not covered by the built-in list, we could require people to indicate the necessary headers and signature somehow. Hypothetical notation AC_CHECK_FUNCS([ [argp_parse, [argp.h], [error_t], [const struct argp *, int, char **, unsigned int, int *, void *]] ]) Note that this still isn’t perfect; if some system provides a function with an identical type signature, but different *semantics*, to the one the application wants, no compilation test can detect that. Autoconf’s not going to step away from its “avoid compile-and-run tests, that breaks cross compilation” stance. > I've been writing/complaining about autoconf doing this wrong for > decades, with the best writeup around 9 years ago at > https://ewontfix.com/13/. Part of the reason is that this has bitten > musl libc users over and over again due to configure finding symbols > that were intended only as ABI-compat and trying to use them (without > declarations) at the source level I vaguely recall some cases where this bit glibc and Apple’s libc as well. In principle, you’re supposed to be able to declare some ISO C functions yourself, e.g. extern int printf(const char *, ...); int main(void) { printf("hello world\n"); } is strictly conforming per C99, but this bypasses any symbol renaming applied by stdio.h. > What I'd like to see happen is complete deprecation of the autoconf > link-only tests Do you have a concrete list of documented Autoconf macros that you would like to see deprecated for this reason? zw
