On Mon, 24 May 2010, FX wrote: > 1. assume that the user has compiled compile separately a quad-prec > math library (says libmathq; possible relying on MPFR, as the > implementation I propose) and arrange specs so that an option triggers > linking to it > 2. assume that the user has an MPFR target library compiled, and > include the quad math wrappers into libgfortran
There's also the possibility of dlopening a separate library or MPFR from libgfortran. I suspect it would be hard to make dlopening MPFR work well (too much need to know about MPFR data types in the code using it), but it does avoid bringing a shared library into many programs that do not need it. (So would building a separate libgfortranfloat128 library with the relevant code - built as part of GCC, linked against MPFR but not included in libgfortran.) There was a discussion a while back of the undesirability of making libstdc++ depend on librt. Certainly, "assume" seems wrong - test at configure time, rather, on the platforms supporting float128 libgcc functions, and disable the libgfortran functionality if MPFR isn't present. It's expected that when bootstrapping cross tools for a GNU/Linux target you have shared libc present before building and configuring non-C runtime libraries (and so build the compiler more than once with a C-only compiler used to build glibc). So this would add a rule that if you want MPFR support in libgfortran then you build MPFR with your C-only compiler before building the Fortran-enabled compiler. MPFR requirements could be potentially problematic for bare-metal targets using static linking only (since MPFR is LGPL whereas GCC runtime libraries are GPL+exception) but that's less relevant for the targets that support __float128 at present, all of which support dynamic linking. -- Joseph S. Myers jos...@codesourcery.com
