head 1.1;
branch 1.1.1;
access;
symbols
netbsd-11-0-RC4:1.1.1.7
netbsd-11-0-RC3:1.1.1.7
netbsd-11-0-RC2:1.1.1.7
netbsd-11-0-RC1:1.1.1.7
perseant-exfatfs-base-20250801:1.1.1.7
netbsd-11:1.1.1.7.0.2
netbsd-11-base:1.1.1.7
netbsd-10-1-RELEASE:1.1.1.5
mpfr-4-2-1:1.1.1.7
perseant-exfatfs-base-20240630:1.1.1.6
perseant-exfatfs:1.1.1.6.0.2
perseant-exfatfs-base:1.1.1.6
netbsd-8-3-RELEASE:1.1.1.2
netbsd-9-4-RELEASE:1.1.1.4
netbsd-10-0-RELEASE:1.1.1.5
netbsd-10-0-RC6:1.1.1.5
netbsd-10-0-RC5:1.1.1.5
netbsd-10-0-RC4:1.1.1.5
netbsd-10-0-RC3:1.1.1.5
netbsd-10-0-RC2:1.1.1.5
netbsd-10-0-RC1:1.1.1.5
mpfr-4-2-0:1.1.1.6
netbsd-10:1.1.1.5.0.6
netbsd-10-base:1.1.1.5
netbsd-9-3-RELEASE:1.1.1.4
cjep_sun2x-base1:1.1.1.5
cjep_sun2x:1.1.1.5.0.4
cjep_sun2x-base:1.1.1.5
cjep_staticlib_x-base1:1.1.1.5
netbsd-9-2-RELEASE:1.1.1.4
cjep_staticlib_x:1.1.1.5.0.2
cjep_staticlib_x-base:1.1.1.5
netbsd-9-1-RELEASE:1.1.1.4
mpfr-4-1-0:1.1.1.5
phil-wifi-20200421:1.1.1.4
phil-wifi-20200411:1.1.1.4
is-mlppp:1.1.1.4.0.4
is-mlppp-base:1.1.1.4
phil-wifi-20200406:1.1.1.4
netbsd-8-2-RELEASE:1.1.1.2
netbsd-9-0-RELEASE:1.1.1.4
netbsd-9-0-RC2:1.1.1.4
netbsd-9-0-RC1:1.1.1.4
phil-wifi-20191119:1.1.1.4
netbsd-9:1.1.1.4.0.2
netbsd-9-base:1.1.1.4
phil-wifi-20190609:1.1.1.4
netbsd-8-1-RELEASE:1.1.1.2
netbsd-8-1-RC1:1.1.1.2
pgoyette-compat-merge-20190127:1.1.1.3.2.1
pgoyette-compat-20190127:1.1.1.4
pgoyette-compat-20190118:1.1.1.4
pgoyette-compat-1226:1.1.1.4
pgoyette-compat-1126:1.1.1.4
pgoyette-compat-1020:1.1.1.4
pgoyette-compat-0930:1.1.1.4
pgoyette-compat-0906:1.1.1.4
mpfr-4-0-1:1.1.1.4
netbsd-7-2-RELEASE:1.1.1.2
pgoyette-compat-0728:1.1.1.3
netbsd-8-0-RELEASE:1.1.1.2
phil-wifi:1.1.1.3.0.4
phil-wifi-base:1.1.1.3
pgoyette-compat-0625:1.1.1.3
netbsd-8-0-RC2:1.1.1.2
pgoyette-compat-0521:1.1.1.3
pgoyette-compat-0502:1.1.1.3
pgoyette-compat-0422:1.1.1.3
netbsd-8-0-RC1:1.1.1.2
pgoyette-compat-0415:1.1.1.3
pgoyette-compat-0407:1.1.1.3
pgoyette-compat-0330:1.1.1.3
pgoyette-compat-0322:1.1.1.3
pgoyette-compat-0315:1.1.1.3
netbsd-7-1-2-RELEASE:1.1.1.2
pgoyette-compat:1.1.1.3.0.2
pgoyette-compat-base:1.1.1.3
netbsd-7-1-1-RELEASE:1.1.1.2
matt-nb8-mediatek:1.1.1.2.0.22
matt-nb8-mediatek-base:1.1.1.2
mpfr-3-1-5:1.1.1.3
perseant-stdc-iso10646:1.1.1.2.0.20
perseant-stdc-iso10646-base:1.1.1.2
netbsd-8:1.1.1.2.0.18
netbsd-8-base:1.1.1.2
prg-localcount2-base3:1.1.1.2
prg-localcount2-base2:1.1.1.2
prg-localcount2-base1:1.1.1.2
prg-localcount2:1.1.1.2.0.16
prg-localcount2-base:1.1.1.2
pgoyette-localcount-20170426:1.1.1.2
bouyer-socketcan-base1:1.1.1.2
pgoyette-localcount-20170320:1.1.1.2
netbsd-7-1:1.1.1.2.0.14
netbsd-7-1-RELEASE:1.1.1.2
netbsd-7-1-RC2:1.1.1.2
netbsd-7-nhusb-base-20170116:1.1.1.2
bouyer-socketcan:1.1.1.2.0.12
bouyer-socketcan-base:1.1.1.2
pgoyette-localcount-20170107:1.1.1.2
netbsd-7-1-RC1:1.1.1.2
pgoyette-localcount-20161104:1.1.1.2
netbsd-7-0-2-RELEASE:1.1.1.2
localcount-20160914:1.1.1.2
netbsd-7-nhusb:1.1.1.2.0.10
netbsd-7-nhusb-base:1.1.1.2
pgoyette-localcount-20160806:1.1.1.2
pgoyette-localcount-20160726:1.1.1.2
pgoyette-localcount:1.1.1.2.0.8
pgoyette-localcount-base:1.1.1.2
netbsd-7-0-1-RELEASE:1.1.1.2
netbsd-7-0:1.1.1.2.0.6
netbsd-7-0-RELEASE:1.1.1.2
netbsd-7-0-RC3:1.1.1.2
netbsd-7-0-RC2:1.1.1.2
netbsd-7-0-RC1:1.1.1.2
netbsd-6-0-6-RELEASE:1.1.1.1
netbsd-6-1-5-RELEASE:1.1.1.1
netbsd-7:1.1.1.2.0.4
netbsd-7-base:1.1.1.2
yamt-pagecache-base9:1.1.1.2
yamt-pagecache-tag8:1.1.1.1
netbsd-6-1-4-RELEASE:1.1.1.1
netbsd-6-0-5-RELEASE:1.1.1.1
tls-earlyentropy:1.1.1.2.0.2
tls-earlyentropy-base:1.1.1.2
riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.2
riastradh-drm2-base3:1.1.1.2
netbsd-6-1-3-RELEASE:1.1.1.1
netbsd-6-0-4-RELEASE:1.1.1.1
mpfr-3-1-2:1.1.1.2
netbsd-6-1-2-RELEASE:1.1.1.1
netbsd-6-0-3-RELEASE:1.1.1.1
netbsd-6-1-1-RELEASE:1.1.1.1
riastradh-drm2-base2:1.1.1.1
riastradh-drm2-base1:1.1.1.1
riastradh-drm2:1.1.1.1.0.12
riastradh-drm2-base:1.1.1.1
netbsd-6-1:1.1.1.1.0.16
netbsd-6-0-2-RELEASE:1.1.1.1
netbsd-6-1-RELEASE:1.1.1.1
netbsd-6-1-RC4:1.1.1.1
netbsd-6-1-RC3:1.1.1.1
agc-symver:1.1.1.1.0.14
agc-symver-base:1.1.1.1
netbsd-6-1-RC2:1.1.1.1
netbsd-6-1-RC1:1.1.1.1
yamt-pagecache-base8:1.1.1.1
netbsd-6-0-1-RELEASE:1.1.1.1
yamt-pagecache-base7:1.1.1.1
matt-nb6-plus-nbase:1.1.1.1
yamt-pagecache-base6:1.1.1.1
netbsd-6-0:1.1.1.1.0.10
netbsd-6-0-RELEASE:1.1.1.1
netbsd-6-0-RC2:1.1.1.1
tls-maxphys:1.1.1.1.0.8
tls-maxphys-base:1.1.1.2
matt-nb6-plus:1.1.1.1.0.6
matt-nb6-plus-base:1.1.1.1
netbsd-6-0-RC1:1.1.1.1
yamt-pagecache-base5:1.1.1.1
yamt-pagecache-base4:1.1.1.1
netbsd-6:1.1.1.1.0.4
netbsd-6-base:1.1.1.1
yamt-pagecache-base3:1.1.1.1
yamt-pagecache-base2:1.1.1.1
yamt-pagecache:1.1.1.1.0.2
yamt-pagecache-base:1.1.1.1
mpfr-3-0-1:1.1.1.1
mpfr:1.1.1;
locks; strict;
comment @# @;
1.1
date 2011.06.20.05.53.03; author mrg; state Exp;
branches
1.1.1.1;
next ;
1.1.1.1
date 2011.06.20.05.53.03; author mrg; state Exp;
branches
1.1.1.1.2.1
1.1.1.1.8.1;
next 1.1.1.2;
1.1.1.2
date 2013.11.28.12.30.54; author mrg; state Exp;
branches;
next 1.1.1.3;
commitid suMNN8knGTUjE2fx;
1.1.1.3
date 2017.08.17.01.09.24; author mrg; state Exp;
branches
1.1.1.3.2.1
1.1.1.3.4.1;
next 1.1.1.4;
commitid byVWLjxDrcX5fv3A;
1.1.1.4
date 2018.09.04.05.02.01; author mrg; state Exp;
branches;
next 1.1.1.5;
commitid aNyHel12V2dWaKQA;
1.1.1.5
date 2020.09.26.07.25.39; author mrg; state Exp;
branches;
next 1.1.1.6;
commitid uDXWuNicgnpBNwpC;
1.1.1.6
date 2023.03.05.22.08.36; author mrg; state Exp;
branches
1.1.1.6.2.1;
next 1.1.1.7;
commitid AcBV1jKMu2z25ZfE;
1.1.1.7
date 2024.07.01.02.24.30; author mrg; state Exp;
branches;
next ;
commitid E5dBeg2NyM7QV4gF;
1.1.1.1.2.1
date 2014.05.22.14.09.14; author yamt; state Exp;
branches;
next ;
commitid nx2BSsHy0NPeAxBx;
1.1.1.1.8.1
date 2014.08.20.00.00.03; author tls; state Exp;
branches;
next ;
commitid jTnpym9Qu0o4R1Nx;
1.1.1.3.2.1
date 2018.09.06.06.53.45; author pgoyette; state Exp;
branches;
next ;
commitid HCi1bXD317XIK0RA;
1.1.1.3.4.1
date 2019.06.10.22.02.26; author christos; state Exp;
branches;
next ;
commitid jtc8rnCzWiEEHGqB;
1.1.1.6.2.1
date 2025.08.02.05.50.23; author perseant; state Exp;
branches;
next ;
commitid 23j6GFaDws3O875G;
desc
@@
1.1
log
@Initial revision
@
text
@Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
Contributed by the Arenaire and Cacao projects, INRIA.
This file is part of the GNU MPFR Library.
The GNU MPFR Library is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at your
option) any later version.
The GNU MPFR Library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public
License for more details.
You should have received a copy of the GNU Lesser General Public License
along with the GNU MPFR Library; see the file COPYING.LESSER. If not, see
http://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc.,
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
Installing GNU MPFR
===================
Note: In case of problem, please read this INSTALL file carefully before
reporting a bug, in particular Section "In case of problem" below. Some
problems are due to bad configuration on the user side (not specific to
MPFR).
0. You first need to install GMP. See .
MPFR requires GMP version 4.1 or later.
1. Extract the files from the archive.
2. It is strongly advised to apply the latest patches (if this has
not been done yet), e.g.
wget http://www.mpfr.org/mpfr-3.0.1/allpatches
patch -N -Z -p1 < allpatches
or
curl http://www.mpfr.org/mpfr-3.0.1/allpatches | patch -N -Z -p1
(Those instructions are for the GNU patch command, for example
/usr/bin/gpatch on Solaris.)
3. In the MPFR directory, to detect your system, type:
./configure
possibly with options (see below, in particular if this step or
one of the following fails).
Note: paths provided in configure options must always be absolute
(relative paths are not supported).
4. To build the library, type:
make
[optional] if you want to tune MPFR for your specific architecture, see
the section "Tuning MPFR" below. Note that for most common architectures,
MPFR includes some default tuning parameters which should be near from
optimal.
5. To check the built library (runs the test files), type:
make check
6. To install it (default "/usr/local" | see "--prefix" option), type:
make install
If you installed MPFR (header and library) in directories that are
not searched by default by the compiler and/or linking tools, then,
like with other libraries, you may need to set up some environment
variables such as C_INCLUDE_PATH (to find the header mpfr.h),
LIBRARY_PATH (to find the library), and if the shared library has
been installed, LD_LIBRARY_PATH (before execution) or LD_RUN_PATH
(before linking); this list is not exhaustive and some environment
variables may be specific to your system. "make install" gives some
instructions; please read them. You can also find more information
in the manuals of your compiler and linker. The MPFR FAQ may also
give some information.
Remember that if you have several MPFR (or GMP) versions installed
(e.g., one with the system, and one, newer, by you), you will not
necessarily get a compilation/linking error if a wrong library is
used (e.g., because LD_LIBRARY_PATH has not been set correctly).
But unexpected results may occur.
Under Mac OS X, if the shared library was not installed and you use
Apple's linker (this is the default), you will also need to provide
the -search_paths_first linker flag ("-Wl,-search_paths_first" when
you link via gcc) to make sure that the right library is selected,
as by default, Apple's linker selects a shared library preferably,
even when it is farther in the library paths. We recall that if a
wrong library is selected due to this behavior, unexpected results
may occur.
Building the documentation
==========================
To build the documentation in various formats, you may first need to
install recent versions of some utilities such as texinfo.
* Type "make info" to produce the documentation in the info format.
* Type "make pdf" to produce the documentation in the PDF format.
* Type "make dvi" to produce the documentation in the DVI format.
* Type "make ps" to produce the documentation in the Postscript format.
* Type "make html" to produce the documentation in the HTML format
(in several pages); if you want only one output HTML file, then
type "makeinfo --html --no-split mpfr.texi" instead.
Building MPFR with internal GMP header files
============================================
MPFR built with internal GMP header files is a bit faster, so you may want
to build it with them. Just do this in step 1:
./configure --with-gmp-build=GMPBUILD
where GMPBUILD is the GMP build directory. The needed header files are:
gmp-impl.h, longlong.h and all the necessary headers to use them.
As gmp-impl.h and longlong.h are only in the GMP source directory,
you first need to copy these files to the build directory if it is
different (there may be other workarounds, such as setting $CPPFLAGS
to search the GMP source directory).
Warning: the library obtained in this way may use some internal GMP
symbols, and thus dynamically linking your software with a different
version of GMP might fail, even though it is declared as compatible
by Libtool's versioning system.
Tuning MPFR
===========
For this, you need to build MPFR with a GMP build directory (see above).
In the GMP build directory, you also need to go into the "tune" subdirectory
and type "make speed". This will build the GMP speed library, which is used
by the MPFR tuning mechanism.
Then go back to the MPFR build directory, and type "make tune". This will
build an optimized file "mparam.h" for your specific architecture.
./configure options
===================
--prefix=DIR installs MPFR headers and library in DIR/include and
DIR/lib respectively (the default is "/usr/local").
--with-gmp-include=DIR assumes that DIR contains gmp.h
--with-gmp-lib=DIR assumes that DIR contains the GMP library
--with-gmp=DIR assumes that DIR is where you have installed GMP.
same as --with-gmp-lib=DIR/lib
and --with-gmp-include=DIR/include
(use either --with-gmp alone or one or both of
--with-gmp-lib/--with-gmp-include)
Warning! Do not use these options if you have
CPPFLAGS and/or LDFLAGS containing a -I or -L
option with a directory that contains a GMP
header or library file, as these options just
add -I and -L options to CPPFLAGS and LDFLAGS
*after* the ones that are currently declared,
so that DIR will have a lower precedence. Also,
this may not work if DIR is a system directory.
--with-gmp-build=DIR assumes that DIR contains the GMP build directory,
and enables the use of GMP internals (see above).
Warning! This option and the group of options
--with-gmp are mutually exclusive.
--enable-assert build MPFR with assertions.
--enable-thread-safe build MPFR as thread safe, using compiler-level
Thread Local Storage (TLS). Note: TLS support is
roughly tested by configure. If configure detects
that TLS does not work (because of the compiler,
linker or system libraries), it will output an
error message, telling you to build MPFR without
thread safe. For instance, though Mac OS X uses
GCC, it may not currently support GCC's __thread
storage class.
Note: By default, the configure script tries to set CC/CFLAGS to GMP's
ones (this feature needs GMP 4.3.0 or later, or the --with-gmp-build
option). However this is not guaranteed to work as the configure script
does some compiler tests earlier, and the change may be too late. Also,
the values obtained from GMP may be incorrect if GMP has been built
on a different machine. In such a case, the user may need to specify
CC/CFLAGS as explained below.
Run "./configure --help" to see the other options (autoconf default options).
In case of problem
==================
First, look for any warning message in the configure output.
Several documents may help you to solve the problem:
* this INSTALL file, in particular information given below;
* the FAQ (either the FAQ.html file distributed with MPFR, or the
on-line version , which may be more
up-to-date);
* the MPFR web page for this version ,
which lists bugs found in this version and provides some patches.
If the "configure" fails, please check that the C compiler and its
options are the same as those for the GMP build (specially the ABI).
You can see the latter with the following command:
grep "^CC\|^CFLAGS" GMPBUILD/Makefile
if the GMP build directory is available. Then type:
./configure CC= CFLAGS=""
(quotes are needed when there are spaces or other special characters
in the CC/CFLAGS value) and continue the install. On some platforms,
you should provide further options to match those used by GMP, or set
some environment variables. For instance, see the "Notes on AIX/PowerPC"
section below.
Warning! Do NOT use optimization options that can change the semantics
of math operations, such as GCC's -ffast-math or Sun CC's -fast.
Otherwise conversions from/to double's may be incorrect on infinities,
NaN's and signed zeros. Since native FP arithmetic is used in a few
places only, such options would not make MPFR faster anyway.
On some platforms, try with "gmake" (GNU make) instead of "make".
Problems have been reported with the Tru64 make.
If the configure script reports that gmp.h version and libgmp version
are different, or if the build was OK, but the tests failed to link
with GMP or gave an error like
undefined reference to `__gmp_get_memory_functions'
meaning that the GMP library was not found or a wrong GMP library was
selected by the linker, then your library search paths are probably
not correctly set (some paths are missing or they are specified in an
incorrect order).
Such problems commonly occur under some GNU/Linux machines, where the
default header and library search paths may be inconsistent: GCC is
configured to search /usr/local/include and /usr/local/lib by default,
while the dynamic linker ignores /usr/local/lib. If you have a GMP
version installed in /usr (provided by the OS vendor) and a new one
installed in /usr/local, then the header of the new GMP version and
the library of the old GMP version will be used! The best solution
is to make sure that the dynamic linker configuration is consistent
with GCC's behavior, for instance by having /usr/local/lib in
/etc/ld.so.conf or in some file from /etc/ld.so.conf.d (as Debian
did: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395177). See
also http://gcc.gnu.org/ml/gcc-help/2010-01/msg00171.html for more
information. Alternatively you can use:
* environment variables. This may sometimes be necessary. If DIR
is the installation directory of GMP, add DIR/include to your
CPATH or C_INCLUDE_PATH (for compilers other than GCC, please
check the manual of your compiler), and add DIR/lib to your
LIBRARY_PATH and LD_LIBRARY_PATH (and/or LD_RUN_PATH);
* --with-gmp* configure options (described above), e.g.
--with-gmp=/opt/local (to use /opt/local/include for headers and
/opt/local/lib for libraries), but other software that uses GMP
and/or MPFR will need correct paths too, and environment variables
allow one to set such search paths in a global way.
Note about "--with-gmp=/usr/local". This option may appear to
solve the above inconsistency problem, but does not work as you
expect. Indeed it affects the library search path, in particular,
the one used by the dynamic linker (thus adding the missing
/usr/local/lib directory as wanted), but since /usr/local/include
is a "standard system include directory" for GCC, the include
search patch is not changed; this is often not a problem in this
particular case because usually, /usr/local/include is already
last in the include search patch, but this may fail under some
occasions and may trigger obscure errors.
For instance, under Unix, where paths are separated by a colon:
* With POSIX sh-compatible shells (e.g. sh, ksh, bash, zsh):
export C_INCLUDE_PATH="/usr/local/include:/other/path/include"
export LIBRARY_PATH="/usr/local/lib:/other/path/lib"
export LD_LIBRARY_PATH="$LIBRARY_PATH"
* With csh or tcsh:
setenv C_INCLUDE_PATH "/usr/local/include:/other/path/include"
setenv LIBRARY_PATH "/usr/local/lib:/other/path/lib"
setenv LD_LIBRARY_PATH "$LIBRARY_PATH"
If you can't solve your problem, you should contact us at ,
indicating the machine and operating system used (uname -a), the compiler
and version used (gcc -v if you use gcc), the configure options used if
any (including variables such as CC and CFLAGS), the version of GMP and
MPFR used, and a description of the problem encountered. Please send us
also the log of the "configure" (config.log).
Note that even if you can build MPFR with a C++ compiler, you can't run
the test suite: C and C++ are not the same language! You should use a C
compiler instead.
Notes on Mac OS X
=================
If you get an error of the form
ld: pointer in read-only segment not allowed in slidable image...
this can mean that the link is done against a static (GMP) library.
In such a case, you should configure MPFR with --disable-shared to
disable the build of the shared library.
Notes on FreeBSD 4.3
====================
FreeBSD 4.3 is provided with an incorrect header file, and
MPFR tests related to long double's may fail. If you cannot upgrade
the system, you can still use MPFR with FreeBSD 4.3, but you should
not use conversions with the long double type.
Notes on AIX/PowerPC
====================
The following has been tested on AIX 5.3 (powerpc-ibm-aix5.3.0.0) with
gcc 3.3.2 and GMP 4.2.1.
If GMP was built with the 64-bit ABI, before building and testing MPFR,
you should set the OBJECT_MODE environment variable to 64, e.g., with:
export OBJECT_MODE=64
(in a sh-compatible shell). But you should also provide a correct CFLAGS
value to the "configure" script: using --with-gmp-build is not sufficient
due to the early compiler tests, as gcc will not compile any program if
OBJECT_MODE is 64 and the -maix64 option is not provided.
Notes on 32-bit Windows Applications (win32)
============================================
1 - We advise to use MinGW (http://www.mingw.org/), which is simpler and
less demanding than Cygwin. Contrary to Cygwin, it also provides native
Windows code. The binaries compiled with Cygwin require a dynamic
library (cygwin.dll) to work; there is a Cygwin option -mno-cygwin to
build native code, but it may require some non-portable tricks.
2 - If you just want to make a binary with gcc, there is nothing to do:
GMP, MPFR and the program compile exactly as under Linux.
But if you want to generate a library for MinGW from a Cygwin
environment, you may need the -mno-cygwin gcc option (otherwise
a typical error is _P_WAIT being undeclared).
3 - If you want to make libraries to work under another Windows compiler
like Visual C / C++, you have two options. Since the unix-like *.a
library files are compatible with Windows *.lib files, you can simply
rename all *.a libraries to *.lib. The second option is to build
MPFR with the Microsoft Visual Studio compiler to produce Windows
libraries directly (Visual Studio build projects for MPFR are
available at http://fp.gladman.plus.com/computing/gmp4win.htm).
With gmp-4.1.3, the only remaining problem seems to be the "alloca" calls
in GMP. Configuring GMP and MPFR with --enable-alloca=malloc-reentrant
should work (if you build MPFR with GMP internal files).
Or you could add the library
"$MINGWIN$/lib/gcc-lib/mingw32/$VERSION$/libgcc.a"
to your project: it contains all the extra-functions needed by a program
compiled by gcc (division of 64-bit integer, bcopy, alloca...).
Of course, include it if and only if your compiler is not gcc.
4 - On Windows32 / MinGW, if all the tests fail, try to run the test suite
with "make check EXEEXT=".
5 - To avoid using the Microsoft runtime (which might not be conform to ISO C),
you can use the MinGW runtime package (which is an integral part of MinGW).
For example, with MinGW versions 3.15 and later you can get an
ISO-compliant printf() if you compile your application with either
'-ansi', '-posix' or '-D__USE_MINGW_ANSI_STDIO'. For example, you can
compile and test MPFR with CC="gcc -D__USE_MINGW_ANSI_STDIO".
For example under Win32, the following problem has been experienced with
MPFR 2.4.0 RC1 and the MSVC runtime (msvcrt.dll):
Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf%n", ...);
expected: "00000010610209857723, -1.2345678875e+07, 0.032258"
got: "00000010610209857723, -1.2345678875e+07, -0.000000"
FAIL: tsprintf.exe
This error is due to the MSVC runtime not supporting the L length modifier
for formatted output (e.g. printf with %Lf). You can check this with the
following program:
#include
int main (void)
{
long double d = 1. / 31.;
printf ("%Lf\n", d);
return 0;
}
The expected output is 0.032258.
Note: The L modifier has been standard for a long time (it was added
in ISO C89).
Notes on 64-bit Windows Applications (x64)
==========================================
[See the Notes on 32-bit Windows Applications, which might be relevant here,
in particular when running a 64-bit operating system]
Cygwin and MinGW do not yet offer support for native Windows 64 builds but
the 32-bit version of MPFR can be used to build 32-bit applications that
will run on 64-bit Windows systems (see above). MPFR can be built as a native
64-bit static or DLL library for Windows 64 using the Visual Studio build
projects at http://fp.gladman.plus.com/computing/gmp4win.htm.
@
1.1.1.1
log
@initial import of MPRF 3.0.1.
The MPFR library is a C library for multiple-precision floating-point
computations with exact rounding (also called correct rounding). It is
based on the GMP multiple-precision library and should replace the MPF
class in further releases of GMP.
GCC >= 4.2 requires MPFR.
@
text
@@
1.1.1.1.8.1
log
@Rebase to HEAD as of a few days ago.
@
text
@d1 2
a2 2
Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free Software Foundation, Inc.
Contributed by the AriC and Caramel projects, INRIA.
d36 3
a38 10
2. It is strongly advised to apply the latest patches if this has
not been done yet and if patches are available. You can check
on the release page:
http://www.mpfr.org/mpfr-3.1.2/
which may have additional information. The patches can be applied
with commands like:
wget http://www.mpfr.org/mpfr-3.1.2/allpatches
a39 1
d41 1
a41 2
curl http://www.mpfr.org/mpfr-3.1.2/allpatches | patch -N -Z -p1
d44 1
a44 1
/usr/bin/gpatch on Solaris.)
d49 1
a49 3
one of the following fails). You should also check whether WARNING
lines have been output (such a problem may cause a failure in one
of the following steps).
d111 1
a111 2
type "makeinfo --html --no-split mpfr.texi" from the doc directory
instead.
d123 6
a128 4
gmp-impl.h, longlong.h and all the necessary headers to use them, which
may be located either in the GMP source directory or in the GMP build
directory, in case they are different (MPFR takes care of that, as of
MPFR 3.1.0).
d144 2
a145 3
Then go back to the MPFR build directory, go into the "tune" subdirectory and
type "make tune". This will build an optimized file "mparam.h" for your
specific architecture.
d168 1
a168 2
this may not work if DIR is a system directory
(typically /usr or /usr/local); see below.
a186 14
--disable-thread-safe build MPFR without TLS. By default, TLS support
is detected automatically, and MPFR is built as
thread safe if supported. However this detection
is only a heuristic: TLS can be detected as
supported while its support is incomplete or
buggy (MPFR tests may fail). In such a case,
this option is useful.
--enable-gmp-internals allows the MPFR build to use GMP's undocumented
functions (not from the public API). Note that
library versioning is not guaranteed to work if
this option is used. Thus it must not be used in
binary distributions.
a197 99
If 'gmp.h' and 'libgmp' do not match
====================================
Under some circumstances, the configure script may output a message
saying:
'gmp.h' and 'libgmp' seem to have different versions or
we cannot run a program linked with GMP (if you cannot
see the version numbers above). [...]
Even though the configure script does not fail in such a case, this
message most often indicates a real error, which needs to be avoided.
Possible causes are:
* The wanted GMP library does not have the same ABI as the one chosen
to build MPFR. The consequences may be:
- A different GMP library (with the correct ABI) has been found,
but does not have the same version as 'gmp.h'.
- No other GMP libraries have been found (in this case, no version
numbers should be printed above the warning message).
This is incorrect and one of the following steps (make, make check)
will probably fail. GMP (actually gmp.h) now provides CC and CFLAGS
information to select the correct ABI, so that this problem should
no longer occur; but if GMP was provided by a binary package, such
information may not be valid. See the
checking for CC and CFLAGS in gmp.h...
line in the configure output (about the 11th line) and the following
few ones for more information. You may need to reinstall GMP or to
provide your own CC and/or CFLAGS. See also the remaining of this
INSTALL file.
* A configure option like --with-gmp or --with-gmp-include was used
with a system include directory, e.g. one of the following:
--with-gmp=/usr
--with-gmp=/usr/local
--with-gmp-include=/usr/include
--with-gmp-include=/usr/local/include
GCC (and possibly other compilers) will ignore such a directive for
include directories (but this rule is not applied for the library
itself!). This means that the library search paths will be reordered
as declared, but the specified include directory will still be near
the end of the include search paths (thus with a low precedence).
This is not a problem if only one GMP version is installed, but
otherwise, a wrong gmp.h may be chosen, so that the versions of
gmp.h and libgmp may not match. The suggestions are the following:
- If you want to use the GMP version under /usr, then you should
uninstall all the other GMP versions (header and library files)
that may be seen in the search paths, in particular those under
/usr/local.
- If you want to use the GMP version under /usr/local, then you
should uninstall all the other GMP versions (header and library
files) that may be seen in the search paths, but *NOT* the one
under /usr (the version under /usr is provided by the OS vendor,
and changing/removing anything related to it may break your
system, and /usr should have a lower precedence than /usr/local
anyway).
To find where GMP versions have been installed:
$ locate libgmp (if you have a locate database)
and if the compiler is GCC:
$ gcc -print-file-name=libgmp.so (under most systems)
$ gcc -print-file-name=libgmp.dylib (under Mac OS X)
and if this does not work, you may try:
$ gcc -print-search-dirs
* An official GCC version was used under Debian GNU/Linux. Problems
may come from the fact that Debian chose a different convention
for library search paths concerning 32-bit and 64-bit libraries.
A possible problem can be, for instance:
[Debian's GCC, correct library path]
$ gcc -print-file-name=libgmp.so
/home/vlefevre/gmp/athlon64/lib/../lib/libgmp.so
[Official GCC, incorrect library path]
$ gcc-4.3.1 -print-file-name=libgmp.so
/usr/lib/../lib64/libgmp.so
The solution: use a GCC provided by Debian or add symbolic links
such as lib64 -> lib (on 64-bit machines) for your library paths.
* The problem may also be temporary and only due to the fact that
libtool could not be used at this time. This is unlikely, though.
d208 1
a208 1
* the MPFR web page for this version ,
a232 18
If some "make check" tests fail, you can try the --disable-thread-safe
configure option (see the configure options above): it has been reported
that some platforms have buggy TLS support. Before trying this option,
you may want to check in the configure output whether MPFR was built
with TLS support; if yes, you will have a line:
checking for TLS support... yes
Alternatively "grep MPFR_USE_THREAD_SAFE config.log" will show that
MPFR_USE_THREAD_SAFE is defined to 1. If it is "no" (or the variable
is not defined), the --disable-thread-safe option would be useless.
Some tests failure may be due to other compiler bugs, in particular
in optimization code. You can try to build MPFR without compiler
optimizations by giving -O0 (letter O, digit 0) in CFLAGS. If the
MPFR tests no longer fail, this was probably due to a compiler bug,
though we cannot exclude a bug in MPFR. You may want to contact us
(see below), possibly after looking at:
http://www.loria.fr/~zimmerma/software/compilerbugs.html
d293 6
a298 7
If you can't solve your problem, you should contact us via the MPFR
mailing-list , indicating the machine and operating system
used (uname -a), the compiler and version used (gcc -v if you use gcc),
the configure options used if any (including variables such as CC and
CFLAGS), the version of GMP and MPFR used, and a description of the
problem encountered. Please send us also the log of the "configure"
(config.log).
a304 18
Notes about ABI
===============
On 64-bit computers, it may happen that the default ABI (Application Binary
Interface) chosen by MPFR does not correspond to the default one chosen by
the compiler.
In particular, this kind of message may indicate the problem:
/usr/bin/ld: skipping incompatible mpfr/src/.libs/libmpfr.a when searching for -lmpfr
In fact, since MPFR relies on GMP, it uses the same ABI as GMP.
To be sure that your program compiles and links correctly, use the same
compiler flags as MPFR does (look for CFLAGS in config.log).
You might also recompile GMP with a different ABI, with for example
./configure ABI=32.
d343 2
a344 8
MPFR for use with 32-bit Windows Applications (win32)
=====================================================
There are several ways of building MPFR on Windows, the most appropriate
approach depending on how you intend to use the resulting libraries.
a. Using MinGW
==============
d348 3
a350 1
Windows code.
d358 7
a364 3
3 - If you want to make libraries work under another Windows compiler
like Visual C / C++, since the unix-like *.a library files are compatible
with Windows *.lib files, you can simply rename all *.a libraries to *.lib.
a410 71
Note 2: this now works correctly with Visual C++ 2008 and 2010
(tested on Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
15.00.21022.08 for 80x86, Microsoft (R) C/C++ Optimizing Compiler
Version 15.00.21022.08 for x64, Microsoft (R) 32-bit C/C++ Optimizing
Compiler Version 16.00.30319.01 for 80x86, Microsoft (R) C/C++ Optimizing
Compiler Version 16.00.30319.01 for x64).
b. Using Cygwin
===============
This build should be similar to that for MinGW except that the resulting
library depends on the Cygwin DLL and cannot therefore be used with
Visual Studio as with MinGW. Indeed, the binaries compiled with Cygwin
require a dynamic library (cygwin.dll) to work; there is a Cygwin option
-mno-cygwin to build native code, but it may require some non-portable tricks.
In case of failure, you may need to pass LDFLAGS='-shared-libgcc' at the
end of the configure line due to a bug in GCC. Otherwise, if threading
support is not needed, you can configure MPFR with --disable-thread-safe.
c. Using Visual C++ 2008/2010
=============================
Win32 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
will give errors if your version of Visual C++ lacks the 64-bit
compiler and tools. The 32-bit build projects should however work
on Visual C++ 2008, Visual C++ Express 2008 (SP1), Visual C++ 2010
and Visual C++ Express 2010.
MPFR for use with 64-bit Windows Applications (x64)
===================================================
There are two ways of building MPFR for use with 64-bit Windows
applications.
a. Using MinGW64
================
The MinGW64 version of the GCC compiler is now available here:
http://sourceforge.net/projects/mingw-w64/
It can build both GMP and MPFR for 64-bit Windows applications.
b. Using Visual C++ 2008/2010
=============================
x64 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
can only be built if your version of Visual C++ contains the 64-bit
compiler and tools. On Visual C++ 2008, the 64-bit tools are an
option during installation so if you don't have them you will need
to start the Visual Studio installer and add them to your IDE
configuration. On Visual C++ 2010 they are installed by default.
As delivered, Visual C++ Express 2008 SP1 cannot build x64 projects
but the Windows SDK can be added to it to allow this. The IDE then
needs to be configured as described here:
http://msdn.microsoft.com/en-us/library/9yb4317s(VS.80).aspx
to allow x64 builds.
d412 2
a413 2
Visual C++ Express 2010 requires the Windows 7 SDK to be installed
in order to build x64 projects. This SDK is available here:
d415 2
a416 1
http://tinyurl.com/25zz8r6
d418 5
a422 2
In this case, once this SDK has been installed, Visual C++ Express 2010
will build x64 projects without further changes.
@
1.1.1.1.2.1
log
@sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
@
text
@d1 2
a2 2
Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free Software Foundation, Inc.
Contributed by the AriC and Caramel projects, INRIA.
d36 3
a38 10
2. It is strongly advised to apply the latest patches if this has
not been done yet and if patches are available. You can check
on the release page:
http://www.mpfr.org/mpfr-3.1.2/
which may have additional information. The patches can be applied
with commands like:
wget http://www.mpfr.org/mpfr-3.1.2/allpatches
a39 1
d41 1
a41 2
curl http://www.mpfr.org/mpfr-3.1.2/allpatches | patch -N -Z -p1
d44 1
a44 1
/usr/bin/gpatch on Solaris.)
d49 1
a49 3
one of the following fails). You should also check whether WARNING
lines have been output (such a problem may cause a failure in one
of the following steps).
d111 1
a111 2
type "makeinfo --html --no-split mpfr.texi" from the doc directory
instead.
d123 6
a128 4
gmp-impl.h, longlong.h and all the necessary headers to use them, which
may be located either in the GMP source directory or in the GMP build
directory, in case they are different (MPFR takes care of that, as of
MPFR 3.1.0).
d144 2
a145 3
Then go back to the MPFR build directory, go into the "tune" subdirectory and
type "make tune". This will build an optimized file "mparam.h" for your
specific architecture.
d168 1
a168 2
this may not work if DIR is a system directory
(typically /usr or /usr/local); see below.
a186 14
--disable-thread-safe build MPFR without TLS. By default, TLS support
is detected automatically, and MPFR is built as
thread safe if supported. However this detection
is only a heuristic: TLS can be detected as
supported while its support is incomplete or
buggy (MPFR tests may fail). In such a case,
this option is useful.
--enable-gmp-internals allows the MPFR build to use GMP's undocumented
functions (not from the public API). Note that
library versioning is not guaranteed to work if
this option is used. Thus it must not be used in
binary distributions.
a197 99
If 'gmp.h' and 'libgmp' do not match
====================================
Under some circumstances, the configure script may output a message
saying:
'gmp.h' and 'libgmp' seem to have different versions or
we cannot run a program linked with GMP (if you cannot
see the version numbers above). [...]
Even though the configure script does not fail in such a case, this
message most often indicates a real error, which needs to be avoided.
Possible causes are:
* The wanted GMP library does not have the same ABI as the one chosen
to build MPFR. The consequences may be:
- A different GMP library (with the correct ABI) has been found,
but does not have the same version as 'gmp.h'.
- No other GMP libraries have been found (in this case, no version
numbers should be printed above the warning message).
This is incorrect and one of the following steps (make, make check)
will probably fail. GMP (actually gmp.h) now provides CC and CFLAGS
information to select the correct ABI, so that this problem should
no longer occur; but if GMP was provided by a binary package, such
information may not be valid. See the
checking for CC and CFLAGS in gmp.h...
line in the configure output (about the 11th line) and the following
few ones for more information. You may need to reinstall GMP or to
provide your own CC and/or CFLAGS. See also the remaining of this
INSTALL file.
* A configure option like --with-gmp or --with-gmp-include was used
with a system include directory, e.g. one of the following:
--with-gmp=/usr
--with-gmp=/usr/local
--with-gmp-include=/usr/include
--with-gmp-include=/usr/local/include
GCC (and possibly other compilers) will ignore such a directive for
include directories (but this rule is not applied for the library
itself!). This means that the library search paths will be reordered
as declared, but the specified include directory will still be near
the end of the include search paths (thus with a low precedence).
This is not a problem if only one GMP version is installed, but
otherwise, a wrong gmp.h may be chosen, so that the versions of
gmp.h and libgmp may not match. The suggestions are the following:
- If you want to use the GMP version under /usr, then you should
uninstall all the other GMP versions (header and library files)
that may be seen in the search paths, in particular those under
/usr/local.
- If you want to use the GMP version under /usr/local, then you
should uninstall all the other GMP versions (header and library
files) that may be seen in the search paths, but *NOT* the one
under /usr (the version under /usr is provided by the OS vendor,
and changing/removing anything related to it may break your
system, and /usr should have a lower precedence than /usr/local
anyway).
To find where GMP versions have been installed:
$ locate libgmp (if you have a locate database)
and if the compiler is GCC:
$ gcc -print-file-name=libgmp.so (under most systems)
$ gcc -print-file-name=libgmp.dylib (under Mac OS X)
and if this does not work, you may try:
$ gcc -print-search-dirs
* An official GCC version was used under Debian GNU/Linux. Problems
may come from the fact that Debian chose a different convention
for library search paths concerning 32-bit and 64-bit libraries.
A possible problem can be, for instance:
[Debian's GCC, correct library path]
$ gcc -print-file-name=libgmp.so
/home/vlefevre/gmp/athlon64/lib/../lib/libgmp.so
[Official GCC, incorrect library path]
$ gcc-4.3.1 -print-file-name=libgmp.so
/usr/lib/../lib64/libgmp.so
The solution: use a GCC provided by Debian or add symbolic links
such as lib64 -> lib (on 64-bit machines) for your library paths.
* The problem may also be temporary and only due to the fact that
libtool could not be used at this time. This is unlikely, though.
d208 1
a208 1
* the MPFR web page for this version ,
a232 18
If some "make check" tests fail, you can try the --disable-thread-safe
configure option (see the configure options above): it has been reported
that some platforms have buggy TLS support. Before trying this option,
you may want to check in the configure output whether MPFR was built
with TLS support; if yes, you will have a line:
checking for TLS support... yes
Alternatively "grep MPFR_USE_THREAD_SAFE config.log" will show that
MPFR_USE_THREAD_SAFE is defined to 1. If it is "no" (or the variable
is not defined), the --disable-thread-safe option would be useless.
Some tests failure may be due to other compiler bugs, in particular
in optimization code. You can try to build MPFR without compiler
optimizations by giving -O0 (letter O, digit 0) in CFLAGS. If the
MPFR tests no longer fail, this was probably due to a compiler bug,
though we cannot exclude a bug in MPFR. You may want to contact us
(see below), possibly after looking at:
http://www.loria.fr/~zimmerma/software/compilerbugs.html
d293 6
a298 7
If you can't solve your problem, you should contact us via the MPFR
mailing-list , indicating the machine and operating system
used (uname -a), the compiler and version used (gcc -v if you use gcc),
the configure options used if any (including variables such as CC and
CFLAGS), the version of GMP and MPFR used, and a description of the
problem encountered. Please send us also the log of the "configure"
(config.log).
a304 18
Notes about ABI
===============
On 64-bit computers, it may happen that the default ABI (Application Binary
Interface) chosen by MPFR does not correspond to the default one chosen by
the compiler.
In particular, this kind of message may indicate the problem:
/usr/bin/ld: skipping incompatible mpfr/src/.libs/libmpfr.a when searching for -lmpfr
In fact, since MPFR relies on GMP, it uses the same ABI as GMP.
To be sure that your program compiles and links correctly, use the same
compiler flags as MPFR does (look for CFLAGS in config.log).
You might also recompile GMP with a different ABI, with for example
./configure ABI=32.
d343 2
a344 8
MPFR for use with 32-bit Windows Applications (win32)
=====================================================
There are several ways of building MPFR on Windows, the most appropriate
approach depending on how you intend to use the resulting libraries.
a. Using MinGW
==============
d348 3
a350 1
Windows code.
d358 7
a364 3
3 - If you want to make libraries work under another Windows compiler
like Visual C / C++, since the unix-like *.a library files are compatible
with Windows *.lib files, you can simply rename all *.a libraries to *.lib.
a410 71
Note 2: this now works correctly with Visual C++ 2008 and 2010
(tested on Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
15.00.21022.08 for 80x86, Microsoft (R) C/C++ Optimizing Compiler
Version 15.00.21022.08 for x64, Microsoft (R) 32-bit C/C++ Optimizing
Compiler Version 16.00.30319.01 for 80x86, Microsoft (R) C/C++ Optimizing
Compiler Version 16.00.30319.01 for x64).
b. Using Cygwin
===============
This build should be similar to that for MinGW except that the resulting
library depends on the Cygwin DLL and cannot therefore be used with
Visual Studio as with MinGW. Indeed, the binaries compiled with Cygwin
require a dynamic library (cygwin.dll) to work; there is a Cygwin option
-mno-cygwin to build native code, but it may require some non-portable tricks.
In case of failure, you may need to pass LDFLAGS='-shared-libgcc' at the
end of the configure line due to a bug in GCC. Otherwise, if threading
support is not needed, you can configure MPFR with --disable-thread-safe.
c. Using Visual C++ 2008/2010
=============================
Win32 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
will give errors if your version of Visual C++ lacks the 64-bit
compiler and tools. The 32-bit build projects should however work
on Visual C++ 2008, Visual C++ Express 2008 (SP1), Visual C++ 2010
and Visual C++ Express 2010.
MPFR for use with 64-bit Windows Applications (x64)
===================================================
There are two ways of building MPFR for use with 64-bit Windows
applications.
a. Using MinGW64
================
The MinGW64 version of the GCC compiler is now available here:
http://sourceforge.net/projects/mingw-w64/
It can build both GMP and MPFR for 64-bit Windows applications.
b. Using Visual C++ 2008/2010
=============================
x64 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
can only be built if your version of Visual C++ contains the 64-bit
compiler and tools. On Visual C++ 2008, the 64-bit tools are an
option during installation so if you don't have them you will need
to start the Visual Studio installer and add them to your IDE
configuration. On Visual C++ 2010 they are installed by default.
As delivered, Visual C++ Express 2008 SP1 cannot build x64 projects
but the Windows SDK can be added to it to allow this. The IDE then
needs to be configured as described here:
http://msdn.microsoft.com/en-us/library/9yb4317s(VS.80).aspx
to allow x64 builds.
d412 2
a413 2
Visual C++ Express 2010 requires the Windows 7 SDK to be installed
in order to build x64 projects. This SDK is available here:
d415 2
a416 1
http://tinyurl.com/25zz8r6
d418 5
a422 2
In this case, once this SDK has been installed, Visual C++ Express 2010
will build x64 projects without further changes.
@
1.1.1.2
log
@initial import of MPFR 3.1.2. changes since 3.0.1:
- Bug fixes (see or ChangeLog file).
- Bug fixes (see or ChangeLog file).
- TLS support is now detected automatically. If TLS is supported, MPFR is
built as thread safe by default. To disable TLS explicitly, configure
MPFR with --disable-thread-safe.
- The mpfr_urandom and mpfr_urandomb functions now return identical values
on processors with different word size (assuming the same random seed, and
since the GMP random generator does not depend itself on the word size,
cf http://gmplib.org/list-archives/gmp-devel/2010-September/001642.html).
- The mpfr_add_one_ulp and mpfr_sub_one_ulp macros (which are obsolete and
no more documented) will be removed in a future release.
- Speed improvement for the mpfr_sqr and mpfr_div functions using Mulders'
algorithm. As a consequence, other functions using those routines are
also faster.
- Much faster formatted output (mpfr_printf, etc.) with %Rg and similar.
- New functions mpfr_buildopt_gmpinternals_p, mpfr_buildopt_tune_case,
mpfr_frexp, mpfr_grandom and mpfr_z_sub.
- New divide-by-zero exception (flag) and associated functions.
- Internal change: the logging mechanism has been improved.
- Bug fixes, in particular a huge inefficiency in mpfr_exp (when the
target precision is less than MPFR_EXP_THRESHOLD) on hard-to-round
cases, which can take several minutes.
@
text
@d1 2
a2 2
Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free Software Foundation, Inc.
Contributed by the AriC and Caramel projects, INRIA.
d36 3
a38 10
2. It is strongly advised to apply the latest patches if this has
not been done yet and if patches are available. You can check
on the release page:
http://www.mpfr.org/mpfr-3.1.2/
which may have additional information. The patches can be applied
with commands like:
wget http://www.mpfr.org/mpfr-3.1.2/allpatches
a39 1
d41 1
a41 2
curl http://www.mpfr.org/mpfr-3.1.2/allpatches | patch -N -Z -p1
d44 1
a44 1
/usr/bin/gpatch on Solaris.)
d49 1
a49 3
one of the following fails). You should also check whether WARNING
lines have been output (such a problem may cause a failure in one
of the following steps).
d111 1
a111 2
type "makeinfo --html --no-split mpfr.texi" from the doc directory
instead.
d123 6
a128 4
gmp-impl.h, longlong.h and all the necessary headers to use them, which
may be located either in the GMP source directory or in the GMP build
directory, in case they are different (MPFR takes care of that, as of
MPFR 3.1.0).
d144 2
a145 3
Then go back to the MPFR build directory, go into the "tune" subdirectory and
type "make tune". This will build an optimized file "mparam.h" for your
specific architecture.
d168 1
a168 2
this may not work if DIR is a system directory
(typically /usr or /usr/local); see below.
a186 14
--disable-thread-safe build MPFR without TLS. By default, TLS support
is detected automatically, and MPFR is built as
thread safe if supported. However this detection
is only a heuristic: TLS can be detected as
supported while its support is incomplete or
buggy (MPFR tests may fail). In such a case,
this option is useful.
--enable-gmp-internals allows the MPFR build to use GMP's undocumented
functions (not from the public API). Note that
library versioning is not guaranteed to work if
this option is used. Thus it must not be used in
binary distributions.
a197 99
If 'gmp.h' and 'libgmp' do not match
====================================
Under some circumstances, the configure script may output a message
saying:
'gmp.h' and 'libgmp' seem to have different versions or
we cannot run a program linked with GMP (if you cannot
see the version numbers above). [...]
Even though the configure script does not fail in such a case, this
message most often indicates a real error, which needs to be avoided.
Possible causes are:
* The wanted GMP library does not have the same ABI as the one chosen
to build MPFR. The consequences may be:
- A different GMP library (with the correct ABI) has been found,
but does not have the same version as 'gmp.h'.
- No other GMP libraries have been found (in this case, no version
numbers should be printed above the warning message).
This is incorrect and one of the following steps (make, make check)
will probably fail. GMP (actually gmp.h) now provides CC and CFLAGS
information to select the correct ABI, so that this problem should
no longer occur; but if GMP was provided by a binary package, such
information may not be valid. See the
checking for CC and CFLAGS in gmp.h...
line in the configure output (about the 11th line) and the following
few ones for more information. You may need to reinstall GMP or to
provide your own CC and/or CFLAGS. See also the remaining of this
INSTALL file.
* A configure option like --with-gmp or --with-gmp-include was used
with a system include directory, e.g. one of the following:
--with-gmp=/usr
--with-gmp=/usr/local
--with-gmp-include=/usr/include
--with-gmp-include=/usr/local/include
GCC (and possibly other compilers) will ignore such a directive for
include directories (but this rule is not applied for the library
itself!). This means that the library search paths will be reordered
as declared, but the specified include directory will still be near
the end of the include search paths (thus with a low precedence).
This is not a problem if only one GMP version is installed, but
otherwise, a wrong gmp.h may be chosen, so that the versions of
gmp.h and libgmp may not match. The suggestions are the following:
- If you want to use the GMP version under /usr, then you should
uninstall all the other GMP versions (header and library files)
that may be seen in the search paths, in particular those under
/usr/local.
- If you want to use the GMP version under /usr/local, then you
should uninstall all the other GMP versions (header and library
files) that may be seen in the search paths, but *NOT* the one
under /usr (the version under /usr is provided by the OS vendor,
and changing/removing anything related to it may break your
system, and /usr should have a lower precedence than /usr/local
anyway).
To find where GMP versions have been installed:
$ locate libgmp (if you have a locate database)
and if the compiler is GCC:
$ gcc -print-file-name=libgmp.so (under most systems)
$ gcc -print-file-name=libgmp.dylib (under Mac OS X)
and if this does not work, you may try:
$ gcc -print-search-dirs
* An official GCC version was used under Debian GNU/Linux. Problems
may come from the fact that Debian chose a different convention
for library search paths concerning 32-bit and 64-bit libraries.
A possible problem can be, for instance:
[Debian's GCC, correct library path]
$ gcc -print-file-name=libgmp.so
/home/vlefevre/gmp/athlon64/lib/../lib/libgmp.so
[Official GCC, incorrect library path]
$ gcc-4.3.1 -print-file-name=libgmp.so
/usr/lib/../lib64/libgmp.so
The solution: use a GCC provided by Debian or add symbolic links
such as lib64 -> lib (on 64-bit machines) for your library paths.
* The problem may also be temporary and only due to the fact that
libtool could not be used at this time. This is unlikely, though.
d208 1
a208 1
* the MPFR web page for this version ,
a232 18
If some "make check" tests fail, you can try the --disable-thread-safe
configure option (see the configure options above): it has been reported
that some platforms have buggy TLS support. Before trying this option,
you may want to check in the configure output whether MPFR was built
with TLS support; if yes, you will have a line:
checking for TLS support... yes
Alternatively "grep MPFR_USE_THREAD_SAFE config.log" will show that
MPFR_USE_THREAD_SAFE is defined to 1. If it is "no" (or the variable
is not defined), the --disable-thread-safe option would be useless.
Some tests failure may be due to other compiler bugs, in particular
in optimization code. You can try to build MPFR without compiler
optimizations by giving -O0 (letter O, digit 0) in CFLAGS. If the
MPFR tests no longer fail, this was probably due to a compiler bug,
though we cannot exclude a bug in MPFR. You may want to contact us
(see below), possibly after looking at:
http://www.loria.fr/~zimmerma/software/compilerbugs.html
d293 6
a298 7
If you can't solve your problem, you should contact us via the MPFR
mailing-list , indicating the machine and operating system
used (uname -a), the compiler and version used (gcc -v if you use gcc),
the configure options used if any (including variables such as CC and
CFLAGS), the version of GMP and MPFR used, and a description of the
problem encountered. Please send us also the log of the "configure"
(config.log).
a304 18
Notes about ABI
===============
On 64-bit computers, it may happen that the default ABI (Application Binary
Interface) chosen by MPFR does not correspond to the default one chosen by
the compiler.
In particular, this kind of message may indicate the problem:
/usr/bin/ld: skipping incompatible mpfr/src/.libs/libmpfr.a when searching for -lmpfr
In fact, since MPFR relies on GMP, it uses the same ABI as GMP.
To be sure that your program compiles and links correctly, use the same
compiler flags as MPFR does (look for CFLAGS in config.log).
You might also recompile GMP with a different ABI, with for example
./configure ABI=32.
d343 2
a344 8
MPFR for use with 32-bit Windows Applications (win32)
=====================================================
There are several ways of building MPFR on Windows, the most appropriate
approach depending on how you intend to use the resulting libraries.
a. Using MinGW
==============
d348 3
a350 1
Windows code.
d358 7
a364 3
3 - If you want to make libraries work under another Windows compiler
like Visual C / C++, since the unix-like *.a library files are compatible
with Windows *.lib files, you can simply rename all *.a libraries to *.lib.
a410 71
Note 2: this now works correctly with Visual C++ 2008 and 2010
(tested on Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
15.00.21022.08 for 80x86, Microsoft (R) C/C++ Optimizing Compiler
Version 15.00.21022.08 for x64, Microsoft (R) 32-bit C/C++ Optimizing
Compiler Version 16.00.30319.01 for 80x86, Microsoft (R) C/C++ Optimizing
Compiler Version 16.00.30319.01 for x64).
b. Using Cygwin
===============
This build should be similar to that for MinGW except that the resulting
library depends on the Cygwin DLL and cannot therefore be used with
Visual Studio as with MinGW. Indeed, the binaries compiled with Cygwin
require a dynamic library (cygwin.dll) to work; there is a Cygwin option
-mno-cygwin to build native code, but it may require some non-portable tricks.
In case of failure, you may need to pass LDFLAGS='-shared-libgcc' at the
end of the configure line due to a bug in GCC. Otherwise, if threading
support is not needed, you can configure MPFR with --disable-thread-safe.
c. Using Visual C++ 2008/2010
=============================
Win32 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
will give errors if your version of Visual C++ lacks the 64-bit
compiler and tools. The 32-bit build projects should however work
on Visual C++ 2008, Visual C++ Express 2008 (SP1), Visual C++ 2010
and Visual C++ Express 2010.
MPFR for use with 64-bit Windows Applications (x64)
===================================================
There are two ways of building MPFR for use with 64-bit Windows
applications.
a. Using MinGW64
================
The MinGW64 version of the GCC compiler is now available here:
http://sourceforge.net/projects/mingw-w64/
It can build both GMP and MPFR for 64-bit Windows applications.
b. Using Visual C++ 2008/2010
=============================
x64 versions of the MPFR library can be built using Microsoft Visual
C++ 2008 or 2010 using the build projects available here:
http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php
These build projects contain both win32 and x64 builds but the latter
can only be built if your version of Visual C++ contains the 64-bit
compiler and tools. On Visual C++ 2008, the 64-bit tools are an
option during installation so if you don't have them you will need
to start the Visual Studio installer and add them to your IDE
configuration. On Visual C++ 2010 they are installed by default.
As delivered, Visual C++ Express 2008 SP1 cannot build x64 projects
but the Windows SDK can be added to it to allow this. The IDE then
needs to be configured as described here:
http://msdn.microsoft.com/en-us/library/9yb4317s(VS.80).aspx
to allow x64 builds.
d412 2
a413 2
Visual C++ Express 2010 requires the Windows 7 SDK to be installed
in order to build x64 projects. This SDK is available here:
d415 2
a416 1
http://tinyurl.com/25zz8r6
d418 5
a422 2
In this case, once this SDK has been installed, Visual C++ Express 2010
will build x64 projects without further changes.
@
1.1.1.3
log
@initial import of MPFR 3.1.5 package. changes since 3.1.2:
Changes from version 3.1.4 to version 3.1.5:
- C++11 compatibility.
- Bug fixes (see and ChangeLog file).
- More tests.
Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see and ChangeLog file).
- MinGW (MS Windows): Added support for thread-safe DLL (shared library).
Changes from version 3.1.2 to version 3.1.3:
- Better support for Automake 1.13+ (now used to generate the tarball).
- Improved MPFR manual.
- Bug fixes (see and ChangeLog file).
@
text
@d1 2
a2 2
Copyright 1999-2016 Free Software Foundation, Inc.
Contributed by the AriC and Caramba projects, INRIA.
d40 1
a40 1
http://www.mpfr.org/mpfr-3.1.5/
d45 1
a45 1
wget http://www.mpfr.org/mpfr-3.1.5/allpatches
d50 1
a50 1
curl http://www.mpfr.org/mpfr-3.1.5/allpatches | patch -N -Z -p1
a74 8
Note: If any test fails, information about this failure can be found in
the tests/test-suite.log file; you should provide this file in your bug
reports (in addition to other useful information, as mentioned later).
If you want the contents of this file to be automatically output in case
of failure, you can set the VERBOSE environment variable to 1 before
running "make check", for instance by typing:
VERBOSE=1 make check
d333 1
a333 1
* the MPFR web page for this version ,
d400 2
a401 2
did: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395177). See
also https://gcc.gnu.org/ml/gcc-help/2010-01/msg00171.html for more
d441 1
a441 2
problem encountered, in particular the tests/test-suite.log file if
"make check" failed. Please send us also the log of the "configure"
d491 2
a492 2
The following has been tested on AIX 7.1.3 (gcc111.fsffrance.org)
with gcc 4.8.1 and GMP 6.1.0.
d499 4
a502 2
(in a sh-compatible shell). Alternatively add the following to the configure
line: AR="ar -X64" NM="nm -B -X64".
d505 2
a506 2
MPFR for use with Windows Applications
======================================
d514 3
a516 4
1 - We advise to use MinGW (http://www.mingw.org/ for 32-bit, and
https://sourceforge.net/projects/mingw-w64/ for 32- and 64-bit),
which is simpler and less demanding than Cygwin. Contrary to Cygwin,
it also provides native Windows code.
d520 20
d541 1
a541 1
3 - To avoid using the Microsoft runtime (which might not be conform to ISO C),
d545 34
a578 6
'-ansi', '-posix' or '-D__USE_MINGW_ANSI_STDIO'. In order to have the
MPFR formatted output functions based on ISO-compliant printf(), you
need to compile GMP (not MPFR) with CC="gcc -D__USE_MINGW_ANSI_STDIO"
(since the standard printf modifiers %Ld and %td are passed to GMP).
Building MPFR with -D__USE_MINGW_ANSI_STDIO is useless except for some
error messages in the test suite.
d593 43
a635 2
c. Using Microsoft Visual C++ and Intel C++ Compilers
=====================================================
d637 3
a639 3
Static and dynamic MPFR libraries for the 32- and 64-bit versions of
Windows can be built with Microsoft Visual Studio 2015 using the
Microsoft Visual C++ compiler, see:
d641 1
a641 1
https://www.visualstudio.com/
d643 1
a643 2
The Intel C++ compiler provided as a part of Intel Parallel Studio XE
can also be used:
d645 2
a646 1
https://software.intel.com/en-us/intel-parallel-studio-xe
d648 1
a648 1
The relevant build projects are available here:
d650 2
a651 1
https://github.com/BrianGladman
@
1.1.1.3.4.1
log
@Sync with HEAD
@
text
@d1 1
a1 1
Copyright 1999-2018 Free Software Foundation, Inc.
d40 1
a40 1
http://www.mpfr.org/mpfr-4.0.1/
d45 1
a45 1
wget http://www.mpfr.org/mpfr-4.0.1/allpatches
d50 1
a50 1
curl http://www.mpfr.org/mpfr-4.0.1/allpatches | patch -N -Z -p1
d83 1
a83 11
6. [Optional / experimental] Binary distributions may also want to run:
make check-gmp-symbols
This will check that MPFR does not use GMP internal symbols, which
could yield failures in case of GMP upgrade without a MPFR rebuild.
But note that this is a heuristic and might give false positives or
false negatives. Please report any problem to the MPFR developers.
End users may also be interested in this check, unless they have
allowed GMP internals with configure options (see below).
7. To install it (default "/usr/local" | see "--prefix" option), type:
a156 2
[For the current GMP version (6.1.0), a Unix-like OS is required.]
a220 8
--with-sysroot=DIR Search for dependent libraries within DIR (which
may be useful in cross-compilation). If you use
this option, you need to have Libtool 2.4+ on
the target system. See Libtool 2.4+'s NEWS file.
Technical information can be found at [1].
[1] http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/10111
d229 1
a229 6
Moreover, even without --with-gmp-build and --enable-gmp-internals,
MPFR might use some GMP internals by mistake. This would be a bug,
which should be reported to the MPFR developers.
Run "./configure --help" to see the other options (default options
from Autoconf and Automake).
d341 1
a341 1
* the MPFR web page for this version ,
d382 1
a382 1
https://members.loria.fr/PZimmermann/software/compilerbugs.html
a443 17
If almost all the tests fail and the messages in the test-suite.log file
(or in the output, when running individual tests from the command line)
start with a line of the form:
Incorrect MPFR version! (xxx header vs yyy library)
then this means that an installed MPFR version is tested instead of the
one that has just been built. This is probably not a bug in MPFR, but a
problem caused by the user or system configuration (particular options,
environment variables, etc.) or a bug in the toolchain. In particular,
if LD_LIBRARY_PATH overrides the run path (set up by libtool) and an
installed ABI-compatible version of MPFR is in a directory listed in
the LD_LIBRARY_PATH search path, then this will break. An example with
GNU ld:
https://sourceware.org/bugzilla/show_bug.cgi?id=21476
d453 4
a511 13
Notes on Solaris
================
Do not put a -R option in the LD_OPTIONS environment variable, at least
if the directory can contain an MPFR library. Otherwise this MPFR
library may be chosen for the tests (make check) instead of the one that has
just been built, in which case, either you will get errors due to unmatched
versions or this problem may remain undetected. The reason is that this
option will appear before the -R options added by libtool, such as the one
to the src/.libs directory containing the MPFR library that has just been
built, and will have the precedence.
a525 12
If you also use MSYS, you should use "make" for MSYS instead of
the "make" utility from MinGW-W64 or from GCC, which causes the
following error:
libtool: warning: libobj name 'extract.Tpo -c -o extract.lo extract.lo'
may not contain shell special characters.
rm: unknown option -- c
References about this issue and solution:
https://sourceforge.net/p/msys2/tickets/223/
https://sympa.inria.fr/sympa/arc/mpfr/2016-07/msg00009.html
d527 1
a527 3
GMP, MPFR and the program compile exactly as under Linux. (It is
recommended to pass --build=xxx-yyy-mingw64 to the GMP configure command,
or --build=xxx with xxx containing mingw.)
d536 3
a538 21
(since the standard printf modifiers %e, %Ld and %td are passed to GMP).
Not doing so may result in failures of some of the printf-related tests.
For instance, the following error on some Windows machine has been
reported:
https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00053.html
Error in mpfr_vsprintf (s, "%e", ...);
expected: "-1.250000e+000"
got: "-1.250000e+00"
FAIL tsprintf.exe (exit status: 1)
The cause is that here the C functions vsnprintf and vsprintf used
internally in GMP do not produce the same output:
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00045.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00051.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00053.html
Building MPFR with -D__USE_MINGW_ANSI_STDIO is currently useless except
for some error messages in the test suite.
@
1.1.1.3.2.1
log
@Sync with HEAD
Resolve a couple of conflicts (result of the uimin/uimax changes)
@
text
@d1 1
a1 1
Copyright 1999-2018 Free Software Foundation, Inc.
d40 1
a40 1
http://www.mpfr.org/mpfr-4.0.1/
d45 1
a45 1
wget http://www.mpfr.org/mpfr-4.0.1/allpatches
d50 1
a50 1
curl http://www.mpfr.org/mpfr-4.0.1/allpatches | patch -N -Z -p1
d83 1
a83 11
6. [Optional / experimental] Binary distributions may also want to run:
make check-gmp-symbols
This will check that MPFR does not use GMP internal symbols, which
could yield failures in case of GMP upgrade without a MPFR rebuild.
But note that this is a heuristic and might give false positives or
false negatives. Please report any problem to the MPFR developers.
End users may also be interested in this check, unless they have
allowed GMP internals with configure options (see below).
7. To install it (default "/usr/local" | see "--prefix" option), type:
a156 2
[For the current GMP version (6.1.0), a Unix-like OS is required.]
a220 8
--with-sysroot=DIR Search for dependent libraries within DIR (which
may be useful in cross-compilation). If you use
this option, you need to have Libtool 2.4+ on
the target system. See Libtool 2.4+'s NEWS file.
Technical information can be found at [1].
[1] http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/10111
d229 1
a229 6
Moreover, even without --with-gmp-build and --enable-gmp-internals,
MPFR might use some GMP internals by mistake. This would be a bug,
which should be reported to the MPFR developers.
Run "./configure --help" to see the other options (default options
from Autoconf and Automake).
d341 1
a341 1
* the MPFR web page for this version ,
d382 1
a382 1
https://members.loria.fr/PZimmermann/software/compilerbugs.html
a443 17
If almost all the tests fail and the messages in the test-suite.log file
(or in the output, when running individual tests from the command line)
start with a line of the form:
Incorrect MPFR version! (xxx header vs yyy library)
then this means that an installed MPFR version is tested instead of the
one that has just been built. This is probably not a bug in MPFR, but a
problem caused by the user or system configuration (particular options,
environment variables, etc.) or a bug in the toolchain. In particular,
if LD_LIBRARY_PATH overrides the run path (set up by libtool) and an
installed ABI-compatible version of MPFR is in a directory listed in
the LD_LIBRARY_PATH search path, then this will break. An example with
GNU ld:
https://sourceware.org/bugzilla/show_bug.cgi?id=21476
d453 4
a511 13
Notes on Solaris
================
Do not put a -R option in the LD_OPTIONS environment variable, at least
if the directory can contain an MPFR library. Otherwise this MPFR
library may be chosen for the tests (make check) instead of the one that has
just been built, in which case, either you will get errors due to unmatched
versions or this problem may remain undetected. The reason is that this
option will appear before the -R options added by libtool, such as the one
to the src/.libs directory containing the MPFR library that has just been
built, and will have the precedence.
a525 12
If you also use MSYS, you should use "make" for MSYS instead of
the "make" utility from MinGW-W64 or from GCC, which causes the
following error:
libtool: warning: libobj name 'extract.Tpo -c -o extract.lo extract.lo'
may not contain shell special characters.
rm: unknown option -- c
References about this issue and solution:
https://sourceforge.net/p/msys2/tickets/223/
https://sympa.inria.fr/sympa/arc/mpfr/2016-07/msg00009.html
d527 1
a527 3
GMP, MPFR and the program compile exactly as under Linux. (It is
recommended to pass --build=xxx-yyy-mingw64 to the GMP configure command,
or --build=xxx with xxx containing mingw.)
d536 3
a538 21
(since the standard printf modifiers %e, %Ld and %td are passed to GMP).
Not doing so may result in failures of some of the printf-related tests.
For instance, the following error on some Windows machine has been
reported:
https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00053.html
Error in mpfr_vsprintf (s, "%e", ...);
expected: "-1.250000e+000"
got: "-1.250000e+00"
FAIL tsprintf.exe (exit status: 1)
The cause is that here the C functions vsnprintf and vsprintf used
internally in GMP do not produce the same output:
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00045.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00051.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00053.html
Building MPFR with -D__USE_MINGW_ANSI_STDIO is currently useless except
for some error messages in the test suite.
@
1.1.1.4
log
@import mpfr 4.0.1. main changes since 3.1.5 are:
Changes from version 4.0.0 to version 4.0.1:
- Bug fixes (see ChangeLog file), in particular in mpfr_div_ui, which
could yield an incorrectly rounded result to nearest when using
different precisions; this bug had been present since the introduction
of mpfr_div_ui, and in MPFR 4.0.0, it was affecting mpfr_div too.
Changes from versions 3.1.* to version 4.0.0:
- Partial support of MPFR_RNDF (faithful rounding).
- New functions: mpfr_fpif_export and mpfr_fpif_import to export and import
numbers in a floating-point interchange format, independent both on the
number of bits per word and on the endianness.
- New function mpfr_fmodquo to return the low bits of the quotient
corresponding to mpfr_fmod.
- New functions mpfr_flags_clear, mpfr_flags_set, mpfr_flags_test,
mpfr_flags_save and mpfr_flags_restore to operate on groups of flags.
- New functions mpfr_set_float128 and mpfr_get_float128 to convert from/to
the __float128 type (requires --enable-float128 and compiler support).
- New functions mpfr_buildopt_float128_p and mpfr_buildopt_sharedcache_p.
- New functions mpfr_rint_roundeven and mpfr_roundeven, completing the
other similar round-to-integer functions for rounding to nearest with
the even-rounding rule.
- New macro mpfr_round_nearest_away to add partial emulation of the
rounding to nearest-away (as defined in IEEE 754-2008).
- New functions mpfr_nrandom and mpfr_erandom to generate random numbers
following normal and exponential distributions respectively.
- New functions mpfr_fmma and mpfr_fmms to compute a*b+c*d and a*b-c*d.
- New function mpfr_rootn_ui, similar to mpfr_root, but agreeing with the
rootn function of the IEEE 754-2008 standard.
- New functions mpfr_log_ui to compute the logarithm of an integer,
mpfr_gamma_inc for the incomplete Gamma function.
- New function mpfr_beta for the Beta function (incomplete, experimental).
- New function mpfr_get_q to convert a floating-point number into rational.
- Dropped K&R C compatibility.
- Major speedup in mpfr_add, mpfr_sub, mpfr_mul, mpfr_div and mpfr_sqrt when
all operands have the same precision and this precision is less than twice
the number of bits per word, e.g., less than 128 on a 64-bit computer.
- Speedup by a factor of almost 2 in the double <--> mpfr conversions
(mpfr_set_d and mpfr_get_d).
- Speedup in mpfr_log1p and mpfr_atanh for small arguments.
- Speedup in the mpfr_const_euler function (contributed by Fredrik Johansson),
in the computation of Bernoulli numbers (used in mpfr_gamma, mpfr_li2,
mpfr_digamma, mpfr_lngamma and mpfr_lgamma), in mpfr_div, in mpfr_fma
and mpfr_fms.
@
text
@d1 1
a1 1
Copyright 1999-2018 Free Software Foundation, Inc.
d40 1
a40 1
http://www.mpfr.org/mpfr-4.0.1/
d45 1
a45 1
wget http://www.mpfr.org/mpfr-4.0.1/allpatches
d50 1
a50 1
curl http://www.mpfr.org/mpfr-4.0.1/allpatches | patch -N -Z -p1
d83 1
a83 11
6. [Optional / experimental] Binary distributions may also want to run:
make check-gmp-symbols
This will check that MPFR does not use GMP internal symbols, which
could yield failures in case of GMP upgrade without a MPFR rebuild.
But note that this is a heuristic and might give false positives or
false negatives. Please report any problem to the MPFR developers.
End users may also be interested in this check, unless they have
allowed GMP internals with configure options (see below).
7. To install it (default "/usr/local" | see "--prefix" option), type:
a156 2
[For the current GMP version (6.1.0), a Unix-like OS is required.]
a220 8
--with-sysroot=DIR Search for dependent libraries within DIR (which
may be useful in cross-compilation). If you use
this option, you need to have Libtool 2.4+ on
the target system. See Libtool 2.4+'s NEWS file.
Technical information can be found at [1].
[1] http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/10111
d229 1
a229 6
Moreover, even without --with-gmp-build and --enable-gmp-internals,
MPFR might use some GMP internals by mistake. This would be a bug,
which should be reported to the MPFR developers.
Run "./configure --help" to see the other options (default options
from Autoconf and Automake).
d341 1
a341 1
* the MPFR web page for this version ,
d382 1
a382 1
https://members.loria.fr/PZimmermann/software/compilerbugs.html
a443 17
If almost all the tests fail and the messages in the test-suite.log file
(or in the output, when running individual tests from the command line)
start with a line of the form:
Incorrect MPFR version! (xxx header vs yyy library)
then this means that an installed MPFR version is tested instead of the
one that has just been built. This is probably not a bug in MPFR, but a
problem caused by the user or system configuration (particular options,
environment variables, etc.) or a bug in the toolchain. In particular,
if LD_LIBRARY_PATH overrides the run path (set up by libtool) and an
installed ABI-compatible version of MPFR is in a directory listed in
the LD_LIBRARY_PATH search path, then this will break. An example with
GNU ld:
https://sourceware.org/bugzilla/show_bug.cgi?id=21476
d453 4
a511 13
Notes on Solaris
================
Do not put a -R option in the LD_OPTIONS environment variable, at least
if the directory can contain an MPFR library. Otherwise this MPFR
library may be chosen for the tests (make check) instead of the one that has
just been built, in which case, either you will get errors due to unmatched
versions or this problem may remain undetected. The reason is that this
option will appear before the -R options added by libtool, such as the one
to the src/.libs directory containing the MPFR library that has just been
built, and will have the precedence.
a525 12
If you also use MSYS, you should use "make" for MSYS instead of
the "make" utility from MinGW-W64 or from GCC, which causes the
following error:
libtool: warning: libobj name 'extract.Tpo -c -o extract.lo extract.lo'
may not contain shell special characters.
rm: unknown option -- c
References about this issue and solution:
https://sourceforge.net/p/msys2/tickets/223/
https://sympa.inria.fr/sympa/arc/mpfr/2016-07/msg00009.html
d527 1
a527 3
GMP, MPFR and the program compile exactly as under Linux. (It is
recommended to pass --build=xxx-yyy-mingw64 to the GMP configure command,
or --build=xxx with xxx containing mingw.)
d536 3
a538 21
(since the standard printf modifiers %e, %Ld and %td are passed to GMP).
Not doing so may result in failures of some of the printf-related tests.
For instance, the following error on some Windows machine has been
reported:
https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00053.html
Error in mpfr_vsprintf (s, "%e", ...);
expected: "-1.250000e+000"
got: "-1.250000e+00"
FAIL tsprintf.exe (exit status: 1)
The cause is that here the C functions vsnprintf and vsprintf used
internally in GMP do not produce the same output:
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00045.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00051.html
https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00053.html
Building MPFR with -D__USE_MINGW_ANSI_STDIO is currently useless except
for some error messages in the test suite.
@
1.1.1.5
log
@GNU mpfr 4.1.0. main changes from 4.0:
Changed __float128 to the type _Float128 specified in ISO/IEC TS 18661.
__float128 is used as a fallback if _Float128 is not supported.
New function mpfr_get_str_ndigits about conversion to a string of digits.
New function mpfr_dot for the dot product (incomplete, experimental).
New functions mpfr_get_decimal128 and mpfr_set_decimal128 (available
only when MPFR has been built with decimal float support).
New function mpfr_cmpabs_ui.
New function mpfr_total_order_p for the IEEE 754 totalOrder predicate.
The mpfr_out_str function now accepts bases from -2 to -36, in order to
follow mpfr_get_str and GMP's mpf_out_str functions (these cases gave an
assertion failure, as with other invalid bases).
Shared caches: cleanup; really detect lock failures (abort in this case).
Improved mpfr_add and mpfr_sub when all operands have a precision
equal to twice the number of bits per word, e.g., 128 bits on a 64-bit
platform.
Optimized the tuning parameters for various architectures.
@
text
@d1 1
a1 1
Copyright 1999-2020 Free Software Foundation, Inc.
d18 1
a18 1
https://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc.,
d31 2
a32 2
0. You first need to install GMP. See .
MPFR requires GMP version 5.0.0 or later.
d40 1
a40 1
https://www.mpfr.org/mpfr-4.1.0/
d45 1
a45 1
wget https://www.mpfr.org/mpfr-4.1.0/allpatches
d50 1
a50 1
curl https://www.mpfr.org/mpfr-4.1.0/allpatches | patch -N -Z -p1
d210 1
a210 1
Thread-Local Storage (TLS). Note: TLS support is
a226 21
--enable-decimal-float build conversion functions from/to decimal floats.
Note that detection by the configure script is
limited in case of cross-compilation.
Accepted arguments:
yes Decimal support is requested and the configure
script fails if it detects that decimals do not
work.
The encoding (BID or DPD) will automatically be
detected at configure time or at compile time if
possible (if not, generic code will be used).
no Decimal support is explicitly disabled.
auto Decimal support is enabled if the configure script
detects that it works. This is the default when
--{enable,disable}-decimal-float is not given.
bid Decimal support is requested and the encoding is
assumed to be BID (some check may be done).
dpd Decimal support is requested and the encoding is
assumed to be DPD (some check may be done).
generic Decimal support is requested and the generic code
is used (mainly for developers).
d237 3
d241 7
a247 13
Note: By default, the configure script tries to set CC / CFLAGS to GMP's
ones from gmp.h (__GMP_CC / __GMP_CFLAGS) in order to ensure that MPFR is
built with the same ABI as GMP. The reason is that when GMP is built, it
may set CC / CFLAGS to select an ABI that is not the default one in order
to have a better performance. The -pedantic option in GMP's CFLAGS, when
present (which is the case by default), is removed, because the MPFR
build system uses some C extensions (when this script detects that they
are supported) and -pedantic yields too many useless warnings. However,
this setting from GMP is not guaranteed to work as the configure script
does some compiler tests earlier, and a conflict may arise. Also, the
values obtained from GMP may be incorrect for the MPFR build if GMP has
been built on a different machine; in such a case, the user may need to
specify CC / CFLAGS, as explained below.
d364 1
a364 1
on-line version , which may be more
d366 1
a366 1
* the MPFR web page for this version ,
d434 2
a435 2
also https://gcc.gnu.org/legacy-ml/gcc-help/2010-01/msg00171.html for
more information. Alternatively you can use:
d596 9
d606 1
a606 19
With old MinGW versions, you can get an ISO-compliant printf()
if you compile your application with either '-ansi', '-posix' or
'-D__USE_MINGW_ANSI_STDIO'. But note that this latter option,
which was useful in the past (see below) should no longer be used.
The following applies to old MinGW versions, and may be discouraged
with recent MinGW versions.
In order to have the MPFR formatted output functions based on an
ISO-compliant printf(), you need to compile GMP (not MPFR) with
CC="gcc -D__USE_MINGW_ANSI_STDIO" (since the standard printf modifiers
%e, %Ld and %td are passed to GMP).
To avoid failures of some of the printf-related tests, MPFR needs to
be compiled with the same __USE_MINGW_ANSI_STDIO as with GMP, i.e.
this macro should be defined for both or undefined for both; this
should be the case by default, unless CC or CFLAGS has been redefined.
For instance, if __USE_MINGW_ANSI_STDIO is defined in GMP but not in
MPFR, the following error may occur:
d613 2
a614 10
and in the opposite case:
Error in mpfr_vsprintf (s, "%e", ...);
expected: "-1.250000e+00"
got: "-1.250000e+000"
FAIL tsprintf.exe (exit status: 1)
Note with old GMP versions: Other issues could arise due to the fact
that the C functions vsnprintf and vsprintf both used internally in
old GMP versions do not produce the same output:
d620 2
a621 11
If __USE_MINGW_ANSI_STDIO has not been defined when building GMP,
then the length modifiers j, L and t are not supported with the GMP
formatted output functions, and as a consequence, also with MPFR.
This is automatically detected by the configure script, except when
cross-compiling (e.g. under Linux), in which case some macros need
to be defined explicitly, e.g. with
"CPPFLAGS=-DNPRINTF_J -DNPRINTF_L -DNPRINTF_T"
in order to avoid potential issues with the MPFR library and failures
in the test suite (the corresponding tests are disabled explicitly).
d643 1
a643 1
https://visualstudio.microsoft.com/
d648 1
a648 1
https://software.intel.com/en-us/parallel-studio-xe
a652 17
d. Using the CompCert compiler
==============================
[this was tested with CompCert 3.7 and MPFR revision 13851 on x86_64-linux]
CompCert (http://compcert.inria.fr/) is a formally verified compiler.
To compile MPFR with CompCert:
$ ./configure CC=ccomp CFLAGS="-fbitfields -flongdouble -fstruct-passing" --disable-shared
You also need to unset LD_LIBRARY_PATH, and/or you might need to change
wl="" into wl="-Wl," in the libtool file.
All tests (make check) should pass (tget_set_d64, tget_set_d128 and
tset_float128 are skipped, since CompCert does not support _Decimal64,
_Decimal128 nor _Float128).
@
1.1.1.6
log
@initial import of MPFR 4.2.0. changes from 4.1.0 include:
Binary compatible with MPFR 4.0.* and 4.1.*, though some minor changes
in the behavior of the formatted output functions may be visible,
regarded as underspecified behavior or bug fixes (see below).
New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu,
mpfr_atanu and mpfr_atan2u.
New functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi,
mpfr_asinpi, mpfr_atanpi and mpfr_atan2pi.
New functions mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and
mpfr_compound_si.
New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj,
mpfr_pow_sj and mpfr_rootn_si (mpfr_pown is actually a macro defined as
an alias for mpfr_pow_sj).
Bug fixes.
- In particular, for the formatted output functions (mpfr_printf, etc.),
the case where the precision consists only of a period has been fixed to
be like .0 as specified in the ISO C standard, and the manual has been
corrected and clarified.
- The macros of the custom interface have also been fixed:
they now behave like functions (except a minor limitation for
mpfr_custom_init_set).
@
text
@d1 1
a1 1
Copyright 1999-2023 Free Software Foundation, Inc.
a32 5
You need a C compiler, preferably GCC, but any reasonable compiler should
work (C++ compilers should work too, under the condition that they do not
break type punning via union).
And you need the standard Unix "make" command, plus some other standard
Unix utility commands.
d40 1
a40 1
https://www.mpfr.org/mpfr-4.2.0/
d45 1
a45 1
wget --no-config https://www.mpfr.org/mpfr-4.2.0/allpatches
d50 1
a50 1
curl https://www.mpfr.org/mpfr-4.2.0/allpatches | patch -N -Z -p1
d136 1
a136 1
* Type "make ps" to produce the documentation in the PostScript format.
d221 1
a221 1
thread safe if supported. However, this detection
d390 1
a390 1
* the MPFR web page for this version ,
d596 4
a599 3
1 - We advise to use Mingw-w64 (https://www.mingw-w64.org/), which is
simpler and less demanding than Cygwin. Contrary to Cygwin, it also
provides native Windows code.
d602 1
a602 1
the "make" utility from Mingw-w64 or from GCC, which causes the
d621 4
a624 10
With MinGW version v8.0.0 and later, the formatted output functions
(printf, etc.) are ISO/POSIX-conforming by default; however, this is
no longer true if -std=c89 is used at build time. Conversely, with
earlier MinGW versions, it is possible to get conforming functions
with either '-ansi', '-posix' or '-D__USE_MINGW_ANSI_STDIO'. Note
that if there is a conformity mismatch between the options used for
the GMP build (from which the MPFR build gets the output) and those
used for the MPFR tests, the tsprintf test may fail with one of the
errors below. Be careful that a non-conforming output may yield a
buffer overflow.
d630 1
a630 1
ISO-conforming printf(), you need to compile GMP (not MPFR) with
d707 1
a707 1
[Tested with CompCert 3.10 and MPFR master-11992-f75b0c388 on x86_64-linux]
d709 1
a709 1
CompCert (https://compcert.org/) is a formally verified compiler.
d712 1
a712 1
$ ./configure --disable-shared CC=ccomp CFLAGS="-flongdouble -fstruct-passing"
d715 1
a715 1
wl="" into wl="-Wl," in the libtool file (after running configure).
a719 7
e. Using the Intel OneApi compiler
==================================
When using the Intel OneApi compiler (icx), one should add -fp-model=strict
to CFLAGS so that the conversion routines from/to native floating-point
types (float, double, ...) work properly. Otherwise some tests will fail.
@
1.1.1.6.2.1
log
@Sync with HEAD
@
text
@d45 1
a45 1
https://www.mpfr.org/mpfr-4.2.1/
d50 1
a50 1
wget --no-config https://www.mpfr.org/mpfr-4.2.1/allpatches
d55 1
a55 1
curl https://www.mpfr.org/mpfr-4.2.1/allpatches | patch -N -Z -p1
d395 1
a395 1
* the MPFR web page for this version ,
@
1.1.1.7
log
@import MPFR 4.2.1.
mostly a bug-fix release, highlights include:
- abort on lock failure, instead of just warn
- better Inf handling
- fix an unlikely stack overflow in mpfr_rec_sqrt()
- fixes for mpfr_reldiff()
- fix boundary error in mpfr_pow_general()
- fixes to printing Nan and Inf
- many manual and test updates
@
text
@d45 1
a45 1
https://www.mpfr.org/mpfr-4.2.1/
d50 1
a50 1
wget --no-config https://www.mpfr.org/mpfr-4.2.1/allpatches
d55 1
a55 1
curl https://www.mpfr.org/mpfr-4.2.1/allpatches | patch -N -Z -p1
d395 1
a395 1
* the MPFR web page for this version ,
@