| Message ID | alpine.LSU.2.11.1404241011080.18709@zhemvz.fhfr.qr |
|---|---|
| State | New |
| Headers | show |
On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote: > We probably should try to bump the versions used by that script > to something more recent though (should we do that for the 4.9 > branch even?). Any idea what to choose here? I'd say mpc > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > of gmp? We shouldn't change those versions too often, otherwise For gmp 6.0.0, there were some issues with miscompilation of that on Solaris, right? Does it work elsewhere fine? Just fuzzy memories. > -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later) > +@item GNU Multiple Precision Library (GMP) > > -Necessary to build GCC@. If a GMP source distribution is found in a > +Necessary to build GCC@. It can be downloaded from @uref{https://gmplib.org/}. > +Older versions than 4.2.3 will not work. > +If a GMP source distribution is found in a Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3, 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)? Jakub
Richard Biener <rguenther@suse.de> writes: > The GMP people complained that we "advertise" outdated versions > in our install instructions. I tried to address that by not > explicitely listing a "good" version but only mention the version > that is the minimum requirement. I also added a reference to > contrib/download_prerequesites as the recommended way to do > in-tree builds (so we don't get random bugreports for that > with untested combinations of gmp/mpfr/mpc versions). > > We probably should try to bump the versions used by that script > to something more recent though (should we do that for the 4.9 > branch even?). Any idea what to choose here? I'd say mpc > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > of gmp? We shouldn't change those versions too often, otherwise > we end up with a lot of garbage in gcc/infrastructure (we don't > want to break old versions of the script). > > Meanwhile is does the patch look ok? I'd strongly advise against it: in the past we've had serious problems with versions newer than advertised in install.texi on some platforms. Until we have positive evidence that specific newer versions work on a wide range of platforms, we shouldn't suggest to our users that they might. Many users tried with the then-current versions in the past, and the failures are often quite hard to trace back to this. For the 4.9 branch, we should leave this as is: the benefit is almost certainly not worth the trouble. Rainer
On Thu, 24 Apr 2014, Rainer Orth wrote: > Richard Biener <rguenther@suse.de> writes: > > > The GMP people complained that we "advertise" outdated versions > > in our install instructions. I tried to address that by not > > explicitely listing a "good" version but only mention the version > > that is the minimum requirement. I also added a reference to > > contrib/download_prerequesites as the recommended way to do > > in-tree builds (so we don't get random bugreports for that > > with untested combinations of gmp/mpfr/mpc versions). > > > > We probably should try to bump the versions used by that script > > to something more recent though (should we do that for the 4.9 > > branch even?). Any idea what to choose here? I'd say mpc > > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > > of gmp? We shouldn't change those versions too often, otherwise > > we end up with a lot of garbage in gcc/infrastructure (we don't > > want to break old versions of the script). > > > > Meanwhile is does the patch look ok? > > I'd strongly advise against it: in the past we've had serious problems > with versions newer than advertised in install.texi on some platforms. > Until we have positive evidence that specific newer versions work on a > wide range of platforms, we shouldn't suggest to our users that they > might. Many users tried with the then-current versions in the past, and > the failures are often quite hard to trace back to this. Note that I explicitely added the reference to download_prerequesites for the case the user wants/needs to build the libraries together with GCC. That should address this concern, no? > For the 4.9 branch, we should leave this as is: the benefit is almost > certainly not worth the trouble. Of course. Though the version referenced from http://gcc.gnu.org/install is the one from trunk. Richard.
On Thu, 24 Apr 2014, Jakub Jelinek wrote: > On Thu, Apr 24, 2014 at 10:15:31AM +0200, Richard Biener wrote: > > We probably should try to bump the versions used by that script > > to something more recent though (should we do that for the 4.9 > > branch even?). Any idea what to choose here? I'd say mpc > > 1.0.2 is fine, so is mpfr 3.1.2, but should we avoid the 6.0.0 version > > of gmp? We shouldn't change those versions too often, otherwise > > For gmp 6.0.0, there were some issues with miscompilation of that on > Solaris, right? Does it work elsewhere fine? Just fuzzy memories. > > > -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later) > > +@item GNU Multiple Precision Library (GMP) > > > > -Necessary to build GCC@. If a GMP source distribution is found in a > > +Necessary to build GCC@. It can be downloaded from @uref{https://gmplib.org/}. > > +Older versions than 4.2.3 will not work. > > +If a GMP source distribution is found in a > > Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3, > 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)? As I say "will not work" I checked what we reject at configure time (for the oldest versions that work we'll complain "buggy but acceptable"). We can of course make configure more strict and at this time reject the known buggy versions. Shall we do that? Thanks, Richard.
On Thu, Apr 24, 2014 at 10:38:38AM +0200, Richard Biener wrote: > > Is there a reason why you have lowered the minimum versions (4.3.2 -> 4.2.3, > > 2.4.2 -> 2.4.0, 0.8.1 -> 0.8.0)? > > As I say "will not work" I checked what we reject at configure time > (for the oldest versions that work we'll complain "buggy but acceptable"). > We can of course make configure more strict and at this time reject > the known buggy versions. Shall we do that? Ah, ok, guess it is fine then. Dunno what the bugs in the "buggy but acceptable" were, and in any case that can be bumped independently (in both places, configure and web). Jakub
Richard Biener <rguenther@suse.de> writes: >> I'd strongly advise against it: in the past we've had serious problems >> with versions newer than advertised in install.texi on some platforms. >> Until we have positive evidence that specific newer versions work on a >> wide range of platforms, we shouldn't suggest to our users that they >> might. Many users tried with the then-current versions in the past, and >> the failures are often quite hard to trace back to this. > > Note that I explicitely added the reference to download_prerequesites > for the case the user wants/needs to build the libraries together > with GCC. That should address this concern, no? I fear it won't: some people will use it, others just download the latest versions from gmp.org etc. and build them out-of-tree themselves. If we want to recommend newer versions (and no complaint from me there), we should first make sure they work *ourselves* and then again require *those specific versions*, no weasle-wording for anything else, given lots of bad experience in the past. >> For the 4.9 branch, we should leave this as is: the benefit is almost >> certainly not worth the trouble. > > Of course. Though the version referenced from http://gcc.gnu.org/install > is the one from trunk. Unfortunately true. Perhaps we should change that? Rainer
> Meanwhile is does the patch look ok?
No, the current wording is just fine and yours doesn't bring anything (even
the contrary, since you're listing known problematic versions). This will
also break http://gcc.gnu.org/install/specific.html#sparc-x-x
I don't see why we should special case GMP, MPFR and MPC here, look at all the
other dependencies on http://gcc.gnu.org/install/prerequisites.html
And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/
contains obsolete versions.
On Thu, 24 Apr 2014, Eric Botcazou wrote: > > Meanwhile is does the patch look ok? > > No, the current wording is just fine and yours doesn't bring anything (even > the contrary, since you're listing known problematic versions). This will > also break http://gcc.gnu.org/install/specific.html#sparc-x-x Ah, I didn't see that. So the issue here is that the host compiler miscompiles the in-tree copy? Maybe we should compile host libraries with -O0 during stage1 (and require recent host GCC for compiling cross compilers - which we probably do anyway). It's an issue anyway as soon as we bump the versions downloaded by contrib/download_prerequesites. What "newer" versions are affected, btw? Are "very newer" versions fixed maybe? > I don't see why we should special case GMP, MPFR and MPC here, look at all the > other dependencies on http://gcc.gnu.org/install/prerequisites.html > > And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ > contains obsolete versions. Hmm, ok. Is the piece referencing contrib/download_prerequesites and documenting that as the recommended way to setup and do in-tree builds? Generally we have conflicting goals - we want to make sure GCC works with system supplied versions of the libraries (thus the configure version checks), and we want to specify versions that work for the in-tree builds (because of the somewhat awkward setup of the build because of their inter-dependencies and not doing intermediate installs).
On Thu, 24 Apr 2014, Richard Biener wrote: > On Thu, 24 Apr 2014, Eric Botcazou wrote: > > > > Meanwhile is does the patch look ok? > > > > No, the current wording is just fine and yours doesn't bring anything (even > > the contrary, since you're listing known problematic versions). This will > > also break http://gcc.gnu.org/install/specific.html#sparc-x-x > > Ah, I didn't see that. So the issue here is that the host compiler > miscompiles the in-tree copy? Maybe we should compile host libraries with > -O0 during stage1 (and require recent host GCC for compiling > cross compilers - which we probably do anyway). > > It's an issue anyway as soon as we bump the versions downloaded > by contrib/download_prerequesites. What "newer" versions are > affected, btw? Are "very newer" versions fixed maybe? @@ -4321,8 +4330,8 @@ read all other sections that match your Newer versions of the GNU Multiple Precision Library (GMP), the MPFR library and the MPC library are known to be miscompiled by earlier versions of GCC on these platforms. We therefore recommend the use -of the exact versions of these libraries listed as minimal versions -in @uref{prerequisites.html,,the prerequisites}. +of the @command{download_prerequesites} script to download +versions that are known to work. @html <hr /> > > I don't see why we should special case GMP, MPFR and MPC here, look at all the > > other dependencies on http://gcc.gnu.org/install/prerequisites.html > > > > And IIUC the real issue is that ftp://gcc.gnu.org/pub/gcc/infrastructure/ > > contains obsolete versions. > > Hmm, ok. Is the piece referencing contrib/download_prerequesites > and documenting that as the recommended way to setup and do > in-tree builds? > > Generally we have conflicting goals - we want to make sure > GCC works with system supplied versions of the libraries > (thus the configure version checks), and we want to specify > versions that work for the in-tree builds (because of the > somewhat awkward setup of the build because of their inter-dependencies > and not doing intermediate installs). > >
> Ah, I didn't see that. So the issue here is that the host compiler > miscompiles the in-tree copy? Maybe we should compile host libraries with > -O0 during stage1 (and require recent host GCC for compiling > cross compilers - which we probably do anyway). In-tree is a red herring, very few people do that. People download libraries, compile them with the base compiler, install them and bootstrap the compiler. > It's an issue anyway as soon as we bump the versions downloaded > by contrib/download_prerequesites. What "newer" versions are > affected, btw? Are "very newer" versions fixed maybe? GMP 5.x is known to be problematic on SPARC, I don't know for 6.x. > Generally we have conflicting goals - we want to make sure > GCC works with system supplied versions of the libraries > (thus the configure version checks), and we want to specify > versions that work for the in-tree builds (because of the > somewhat awkward setup of the build because of their inter-dependencies > and not doing intermediate installs). Agreed, but the current situation is relatively satisfactory if you ask me. If something needs to be changed because of web/60933, then it's probably the versions provided at ftp://gcc.gnu.org/pub/gcc/infrastructure/
On Fri, 25 Apr 2014, Eric Botcazou wrote: > > Ah, I didn't see that. So the issue here is that the host compiler > > miscompiles the in-tree copy? Maybe we should compile host libraries with > > -O0 during stage1 (and require recent host GCC for compiling > > cross compilers - which we probably do anyway). > > In-tree is a red herring, very few people do that. People download libraries, > compile them with the base compiler, install them and bootstrap the compiler. I'm not sure about that. In fact I'm always suggesting the in-tree variant to people (because then they don't need to fiddle with LD_LIBRARY_PATH). After suggesting to simply install the requirements from vendor provided packages, of course. Maybe we should simply import the requirements into our tree and use them unless the system provides what we need (or --with/without-system-FOO is supplied). We do that for other stuff like zlib, intl, boehm, etc.. gmp 6.0 now has 'mini-gmp' which is a slow but very small variant for example. Not sure if that's enough for our gmp needs for example. > > It's an issue anyway as soon as we bump the versions downloaded > > by contrib/download_prerequesites. What "newer" versions are > > affected, btw? Are "very newer" versions fixed maybe? > > GMP 5.x is known to be problematic on SPARC, I don't know for 6.x. Ok, 6.x is know to be problematic on *BSD. > > Generally we have conflicting goals - we want to make sure > > GCC works with system supplied versions of the libraries > > (thus the configure version checks), and we want to specify > > versions that work for the in-tree builds (because of the > > somewhat awkward setup of the build because of their inter-dependencies > > and not doing intermediate installs). > > Agreed, but the current situation is relatively satisfactory if you ask me. > If something needs to be changed because of web/60933, then it's probably the > versions provided at ftp://gcc.gnu.org/pub/gcc/infrastructure/ Well, if 5.x doesnt' work for SPARC and 6.x doesn't work for *BSD that leaves us with 4.x, exactly what is already present there. Richard.
> I'm not sure about that. In fact I'm always suggesting the in-tree > variant to people (because then they don't need to fiddle with > LD_LIBRARY_PATH). After suggesting to simply install the requirements > from vendor provided packages, of course. The proper fix to the LD_LIBRARY_PATH issue is rather --disable-shared in my opinion... > Maybe we should simply import the requirements into our tree > and use them unless the system provides what we need (or > --with/without-system-FOO is supplied). We do that for other > stuff like zlib, intl, boehm, etc.. gmp 6.0 now has 'mini-gmp' > which is a slow but very small variant for example. Not sure > if that's enough for our gmp needs for example. That would clearly be the definitive answer, but I don't know if it's doable in practice.
Index: gcc/doc/install.texi =================================================================== --- gcc/doc/install.texi (revision 209677) +++ gcc/doc/install.texi (working copy) @@ -351,32 +351,41 @@ versions may work in some cases, but it' versions documented. We appreciate bug reports about problems with newer versions, though. If your OS vendor provides packages for the support libraries then using those packages may be the simplest way to -install the libraries. +install the libraries. If you choose to build the library dependencies +together with GCC you are encouraged to use the +@command{download_prerequesites} script that comes with the GCC +source tarball in the @file{contrib} directory. +This downloads versions that were tested to build and +work ok and prepares the source tree appropriately. @table @asis -@item GNU Multiple Precision Library (GMP) version 4.3.2 (or later) +@item GNU Multiple Precision Library (GMP) -Necessary to build GCC@. If a GMP source distribution is found in a +Necessary to build GCC@. It can be downloaded from @uref{https://gmplib.org/}. +Older versions than 4.2.3 will not work. +If a GMP source distribution is found in a subdirectory of your GCC sources named @file{gmp}, it will be built together with GCC. Alternatively, if GMP is already installed but it is not in your library search path, you will have to configure with the @option{--with-gmp} configure option. See also @option{--with-gmp-lib} and @option{--with-gmp-include}. -@item MPFR Library version 2.4.2 (or later) +@item MPFR Library Necessary to build GCC@. It can be downloaded from -@uref{http://www.mpfr.org/}. If an MPFR source distribution is found +@uref{http://www.mpfr.org/}. Older versions than 2.4.0 will not work. +If an MPFR source distribution is found in a subdirectory of your GCC sources named @file{mpfr}, it will be built together with GCC. Alternatively, if MPFR is already installed but it is not in your default library search path, the @option{--with-mpfr} configure option should be used. See also @option{--with-mpfr-lib} and @option{--with-mpfr-include}. -@item MPC Library version 0.8.1 (or later) +@item MPC Library Necessary to build GCC@. It can be downloaded from -@uref{http://www.multiprecision.org/}. If an MPC source distribution +@uref{http://www.multiprecision.org/}. Older versions than +0.8.0 will not work. If an MPC source distribution is found in a subdirectory of your GCC sources named @file{mpc}, it will be built together with GCC. Alternatively, if MPC is already installed but it is not in your default library search path, the