[Bug libfortran/47196] --disable-libquadmath breaks bootstrap in libgfortran (quadmath_weak.h not found)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47196 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|bootstrap |libfortran Resolution||WONTFIX --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-07 08:52:01 UTC --- I would suggest that you read the libquadmath related part of http://gcc.gnu.org/install/configure.html If you do not want to use libquadmath in libgfortran, build with --disable-libquadmath-support -- or supply a system version of libquadmath library/header files. Whether libquadmath is build (as part of GCC) is independent from whether Fortran (gfortran, libgfortran) uses libquadmath or not. This allows for the following four combination: a) Build libquadmath and Fortran with libquadmath-based REAL(16) support (default on systems where __float128 is supported) b) Build neither libquadmath nor libquadmath-based REAL(16) support (obviously the default on systems lacking __float128 support; Other use: Save a few kilobytes by having one library less) c) Build libquadmath but no Fortran REAL(16) support If one wants to save a few KiB for Fortran but wants to us libquadmath, e.g, with C/C++ 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.
[Bug libfortran/47196] --disable-libquadmath breaks bootstrap in libgfortran (quadmath_weak.h not found)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47196 --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2011-01-07 12:44:17 UTC --- (In reply to comment #1) c) Build libquadmath but no Fortran REAL(16) support If one wants to save a few KiB for Fortran but wants to us libquadmath, e.g, with C/C++ This would be --enable-libquadmath --disable-libquadmath-support? Why should disable-libquadmath-support affect Fortran only (besides that the docs say so)? I'd read this as build libquadmath, but disable any usage within gcc. 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, i.e. instead of the currently necessary --disable-libquadmath --disable-libquadmath-support a simple --disable-libquadmath to turn off everything related to libquadmath would do. If one does not want to build libquadmath of gcc but have libquadmath support for any(!) language, library and headers to be user supplied, then use --disable-libquadmath --enable-libquadmath-support to override the implicit setting of --enable-libquadmath-support. Wouldn't that be much more intuitive and easier for the users?
[Bug libfortran/47196] --disable-libquadmath breaks bootstrap in libgfortran (quadmath_weak.h not found)
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.
