[Bug bootstrap/104301] --enable-cstdio=stdio_pure not passed down to libstdc++-v3

[redi at gcc dot gnu.org]

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.