[Bug libfortran/47196] --disable-libquadmath breaks bootstrap in libgfortran (quadmath_weak.h not found)

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47196

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-07 13:16:48 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > c) Build libquadmath but no Fortran REAL(16) support
> This would be 
>     --enable-libquadmath --disable-libquadmath-support    ?

Yes - though "--enable-libquadmath" is the default and stating it explicitly
wouldn't help on systems which don't have __float128.

> Why should disable-libquadmath-support affect Fortran only (besides that the
> docs say so)?

Because only gfortran (gcc/fortran) and libgfortran/ use this flag. For them
the effect is:
(a) gcc/fortran: Provide a REAL(16) type based on __float128 (TF_MODE) and call
a special libgfortran function for I/O using those types.
(b) libgfortran: Support I/O and some moth functions for __float128 and link
libquadmath.

> I'd read this as "build libquadmath, but disable any usage within gcc"

Well, for C/C++ one does not need a special compiler support: C does not have a
build-in math but one needs to do all the linking and header inclusion
manually. Contrary to Fortran, where the Fortran library does some of the duty
and "COS" is a generic function which takes all kinds of real/complex
arguments.

Thus, for C the library just needs to be compiled and installed - then one can
use it as described at http://gcc.gnu.org/onlinedocs/libquadmath/ (see example
in the "I/O Library Routines" section).

I think for Ada one might need to do something similar, possibly also for Java
and other FE - but currently, Fortran is the only FE+FE-library which uses
libquadmath. Thus, --disable-libquadmath-support currently only applies to
Fortran.

> > d) Don't build libquadmath, but support libquadmath-based REAL(16)
> >    in gfortran
> >    Useful only if the system has already a (compatible) libquadmath 
> >    installation libgfortran then links "-lquadmath" but the user/builder has
> >    to make sure that it is in the -I and the -L paths.
> 
> I think it would make much more sense to set the the libquadmath-support flag
> implicitly in most cases

Well, you assume that the most common case is that one builds Fortran on a
__float128 supporting system but does not want to have REAL(16) support.

I think such a usage is the exception and thus it does not really matter
whether one has to specify only --disable-libquadmath or also
--disable-libquadmath-support.

> Wouldn't that be much more intuitive and easier for the users?

Yes and no. It would be more intuitive to users which do not want to have
libquadmath support in Fortran, but otherwise implicit swapping of defaults is
less intuitive.

At least it is such a special usage with unclear benefit that I won't work on a
patch. But feel free to create one, send it to gcc-patches@ and ask for
build-maintainers' approval.