> DJ, as a build machinery maintainer, you are authorized to approve
> such a patch. Is anything holding you back?
You mean, besides politics?
The last time such a patch came through, we were in the middle of
discussing the various --with-* options. I wanted to let that settle
first.
On Tue, 5 Dec 2006, DJ Delorie wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > > That idea got nixed, but I think it's time to revisit it. Paolo has
> > > worked out the kinks in the configury and we should apply his patch and
> > > import the gmp/mpfr sources, IMHO.
> >
> > Note that thes
On Mon, 4 Dec 2006, DJ Delorie wrote:
> At the very least, we should be configured so that we *could* have an
> in-tree mpfr, should vendors choose to add it. Saving customers the
> misery of figuring out how to build and install gmp/mpfr is the type
> of value add they'd appreciate.
DJ, as a bu
Richard Guenther wrote:
>> As far as I know both versions are released. What I said was
>> "undistributed," by which I mean: the required version of MPFR is not
>> on my relatively up to date Fedora system.
>
> It also missed the openSUSE 10.2 schedule (which has the old version
> with all patch
On 05 Dec 2006 07:16:04 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Brook <[EMAIL PROTECTED]> writes:
> > This all may just be a shakedown problem with MPFR, and maybe it will
> > stabilize shortly. But it's disturbing that after one undistributed
> > version became a requirement, w
Paul Brook <[EMAIL PROTECTED]> writes:
> > This all may just be a shakedown problem with MPFR, and maybe it will
> > stabilize shortly. But it's disturbing that after one undistributed
> > version became a requirement, we then very shortly stepped up to a new
> > undistributed version. I think i
> This all may just be a shakedown problem with MPFR, and maybe it will
> stabilize shortly. But it's disturbing that after one undistributed
> version became a requirement, we then very shortly stepped up to a new
> undistributed version. I think it should be obvious that if we
> require an exte
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> I'm not sure to follow Diego and I am a bit concerned about other
> potential external libraries. Suppose for example that some GCC code
> uses an external library like the Parma Polyedral Library
> http://www.cs.unipr.it/ppl/ (which is very usefu
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > That idea got nixed, but I think it's time to revisit it. Paolo has
> > worked out the kinks in the configury and we should apply his patch and
> > import the gmp/mpfr sources, IMHO.
>
> Note that these two issues (my patch, which by the way was start
Le Tue, Dec 05, 2006 at 07:12:08AM -0500, Diego Novillo écrivait/wrote:
> Kaveh R. GHAZI wrote on 12/04/06 21:32:
> >That idea got nixed, but I think it's time to revisit it. Paolo has
> >worked out the kinks in the configury and we should apply his patch and
> >import the gmp/mpfr sources, IMHO.
Kaveh R. GHAZI wrote on 12/04/06 21:32:
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Yes, I vote to include gmp/mpfr in the tree. If gmp/mpfr is still a
fluid tar
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Note that these two issues (my patch, which by the way was started and
tested by Nick Clifton, and whether to import
On Mon, Dec 04, 2006 at 09:32:19PM -0500, Kaveh R. GHAZI wrote:
> OTOH, Joe you're arguing we should never require people to upgrade. Well
> I think that's unfair to people who rely on gcc to produce correct code.
So, should we detect old binutils versions and refuse to build as well?
How about o
On Mon, 4 Dec 2006, Joe Buck wrote:
> On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> > Hi Vincent, thanks for making this release. Since this version of mpfr
> > fixes important bugs encountered by GCC, I've updated the gcc
> > documentation and error messages to refer to versi
> > I wish we could have similar requirements for GMP and MPFR, rather
> > than requiring the user to pre-install them on pretty much EVERY
> > computer.
>
> Do you mean that gcc should be distributed with GMP and MPFR libraries
> in the tarball? (There had been a discussion about including them
On 2006-12-04 15:34:32 -0500, DJ Delorie wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> > The ordinary user who builds gcc from source does not need *any*
> > version of automake, autoconf, etc., so any strict requirements that
> > are imposed on these tools have an impact only on gcc developers.
Joe Buck <[EMAIL PROTECTED]> writes:
> The ordinary user who builds gcc from source does not need *any*
> version of automake, autoconf, etc., so any strict requirements that
> are imposed on these tools have an impact only on gcc developers.
I wish we could have similar requirements for GMP and
On Mon, Dec 04, 2006 at 02:09:25PM -0500, Richard Kenner wrote:
> > IMHO, you should *never* update gcc's configure to force the issue. To do
> > so would be unprecedented.
>
> I'm not in favor of this either, but aren't there precedents with either
> automake, autoconf, or both?
The ordinary us
> IMHO, you should *never* update gcc's configure to force the issue. To do
> so would be unprecedented.
I'm not in favor of this either, but aren't there precedents with either
automake, autoconf, or both?
On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> Hi Vincent, thanks for making this release. Since this version of mpfr
> fixes important bugs encountered by GCC, I've updated the gcc
> documentation and error messages to refer to version 2.2.1.
>
> I have NOT (yet) updated gcc's
On 2006-12-02 11:41:48 -0800, Bruce Korb wrote:
> Anyway, the whole deal about gmp-config is that mpfr should be doing
> the equivalent of --with-gmp=`gmp-config --libdir` so that you
> *don't* have the /usr/local headers and the /usr binary.
Assuming a gmp-config program is provided, the user can
On 2006-12-02 10:16:31 -0800, Bruce Korb wrote:
> Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
> go pull and build that only to find:
>
> checking if gmp.h version and libgmp version are the same...
> (4.2.1/4.1.4) no
Note that this test was really buggy in MPFR 2.2.0. I f
On Sat, 2 Dec 2006, Kaveh R. GHAZI wrote:
> Gerald, would you please copy the mpfr-2-2.1 tarball to the gcc
> infrastructure directory and delete 2.2.0 and the cumulative patch from
> there? Thanks. http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2
Sure -- done it is.
Gerald
PS: I will most p
Hi Kaveh,
Kaveh R. GHAZI wrote:
>
> It's not clear from your message whether this is a problem limited to
> mpfr-2.2.1, or 2.2.0 had this also. In any case, I think the mpfr
> configure process is right to stop you from shooting yourself by using a
> mismatched gmp header and library.
Here-to-fore
On Sat, 2 Dec 2006, Bruce Korb wrote:
> Hi Kaveh,
>
> Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
> go pull and build that only to find:
>
> checking if gmp.h version and libgmp version are the same...
> (4.2.1/4.1.4) no
>
> which is a problem because I cannot have /usr/lo
Hi Kaveh,
Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
go pull and build that only to find:
checking if gmp.h version and libgmp version are the same...
(4.2.1/4.1.4) no
which is a problem because I cannot have /usr/local/lib found before
/usr/lib for
some things, yet for
On Wed, 29 Nov 2006, Vincent Lefevre wrote:
> MPFR 2.2.1 is now available for download from the MPFR web site:
>
> http://www.mpfr.org/mpfr-2.2.1/
>
> Thanks very much to those who tested the release candidates.
>
> The MD5's:
> 40bf06f8081461d8db7d6f4ad5b9f6bd mpfr-2.2.1.tar.bz2
> 662bc38c75c9
MPFR 2.2.1 is now available for download from the MPFR web site:
http://www.mpfr.org/mpfr-2.2.1/
Thanks very much to those who tested the release candidates.
The MD5's:
40bf06f8081461d8db7d6f4ad5b9f6bd mpfr-2.2.1.tar.bz2
662bc38c75c9857ebbbc34e3280053cd mpfr-2.2.1.tar.gz
93a2bf9dc66f81caa57c
28 matches
Mail list logo
