> 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
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
> 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 peo
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
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#s
> 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,
Richard Biener 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
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 c
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
On Thu, 24 Apr 2014, Rainer Orth wrote:
> Richard Biener 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 re
Richard Biener 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/dow
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 shou
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 recomme
13 matches
Mail list logo
