https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104301
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |minor
Last reconfirmed| |2022-01-31
Ever confirmed|0 |1
Target Milestone|--- |11.3
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to R. Diez from comment #0)
> I guess this is a bug in the top-level 'configure' logic. It has probably
> gone unnoticed for a long time because it is only recently that you can
> specify options other than 'stdio' in --enable-cstdio=xxx .
No, the option is passed down correctly (configure does that automatically).
libstdc++-v3/acinclude.m4 says:
case ${enable_cstdio} in
stdio*)
CSTDIO_H=config/io/c_io_stdio.h
BASIC_FILE_H=config/io/basic_file_stdio.h
BASIC_FILE_CC=config/io/basic_file_stdio.cc
AC_MSG_RESULT(stdio)
So it prints "stdio" for all values, but still handles stdio_pure correctly:
if test "x$enable_cstdio" = "xstdio_pure" ; then
AC_DEFINE(_GLIBCXX_USE_STDIO_PURE, 1,
[Define to restrict std::__basic_file<> to stdio APIs.])
fi
Everything is working fine, it just prints a misleading result. I suppose we
should change the result message to:
AC_MSG_RESULT(${enable_cstdio})
> Or is the GCC user expected to delve down and configure GCC's components
> separately?
No, definitely not.
