subject:"Re\: build failure, GMP not available"


Geoffrey Keating wrote:


do you think this is likely to be:
1. some problem in gmp or mpfr,
2. some problem in my build of gmp and/or mpfr, that wouldn't occur if 
I'd built it in some other (unspecified) way,
3. some problem in my existing system configuration, maybe I already 
have a gmp installed that is somehow conflicting, or

4. a well-known but not serious bug in GCC's Darwin port?


In contrast, as I understand it, Ian's perturbed about the idea of 
having an external library at all.


I don't think Ian would object to an external library that users could 
always find easily, that always built cleanly, that didn't have bugs...  
but such a library doesn't exist.


But, neither does such an internal library exist.  Whether the library 
is part of the GCC source tree or not doesn't affects its quality, or 
even its buildability.  The issue isn't where the source code for the 
library lives, but whether it's any good or not.


I can think of one big advantage of an internal library, though: instead 
of (in addition to?) documenting its build process, you can automate it. 
 One would rather hope that the build process isn't complicated, 
though, in which case this doesn't matter.  After all, we're trying to 
cater to the users for whom "configure; make; make install" works to 
build GCC; as long as the same pattern works for the external libraries, 
I think we're OK.


We might have to improve GMP/MPFR in order to make them work that 
smoothly, but that would have to happen if we imported them too.  So, I 
think you could argue that these libraries are too immature for us to 
depend on in GCC.  But, I don't think that's what Ian was arguing. 
(And, I don't think they're too immature; the problems we're seeing 
don't seem particularly worse than the problems I would expect in early 
Stage 1 with any other kind of big infrastructure change.)


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: build failure, GMP not available

2006-10-31 Thread Andrew Pinski

> 
> > So, now if I tell you that despite all reports that it 'works fine',  
> > I'm getting
> > 
> > > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c  -O0  (test for excess  
> > > errors)
> > 
> > do you think this is likely to be:
> > 1. some problem in gmp or mpfr,
> > 2. some problem in my build of gmp and/or mpfr, that wouldn't occur  
> > if I'd built it in some other (unspecified) way,
> > 3. some problem in my existing system configuration, maybe I already  
> > have a gmp installed that is somehow conflicting, or
> > 4. a well-known but not serious bug in GCC's Darwin port?
> > 
> > It turns out the answer is 4, at least I think it is.
> 
> Actually it is a bug in mpfr which is fixed in the cumulative patch.

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01175.html

Note thata testcase has the following comment:
/* Version 2.2.0 of MPFR had bugs in sin rounding.  This test checks
   to see if that buggy version was installed.  The problem is fixed
   in the MPFR cumulative patch http://www.mpfr.org/mpfr-current and
   presumably later MPFR versions.

   Origin: Kaveh R. Ghazi 10/23/2006.  */

So ...

-- Pinski

Re: build failure, GMP not available

2006-10-31 Thread Andrew Pinski

> So, now if I tell you that despite all reports that it 'works fine',  
> I'm getting
> 
> > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c  -O0  (test for excess  
> > errors)
> 
> do you think this is likely to be:
> 1. some problem in gmp or mpfr,
> 2. some problem in my build of gmp and/or mpfr, that wouldn't occur  
> if I'd built it in some other (unspecified) way,
> 3. some problem in my existing system configuration, maybe I already  
> have a gmp installed that is somehow conflicting, or
> 4. a well-known but not serious bug in GCC's Darwin port?
> 
> It turns out the answer is 4, at least I think it is.

Actually it is a bug in mpfr which is fixed in the cumulative patch.

-- Pinski

Re: build failure, GMP not available

2006-10-31 Thread Geoffrey Keating



On 31/10/2006, at 7:45 AM, Mark Mitchell wrote:


Geoffrey Keating wrote:

OK, I agree: a native compiler, with no special options, isn't  
too hard.  I don't think typing that sequence twice would be too  
hard either, though. :-)
For something that's not too hard, it's sure causing me a lot of  
trouble...


But, the trouble you're having is not because you have to build an  
external library; it's because the external library you're building  
doesn't work on your system, or, at least, doesn't work with  
obvious default build options.


This kind of thing often happens when you have to build an external  
library.  For example, look at the mail that Shantonu sent me while  
we were trying to work out whether GMP did or did not work:


Maybe you have an old version of gmp in your default linker search  
path causing bad things to happen.

...
work around this by setting RANLIB="ranlib -c", so that the  
calling_convention_* symbols get put in the archive table of  
contents so that the Darwin linker loads the archive member on- 
demand from libtests.a


So, now if I tell you that despite all reports that it 'works fine',  
I'm getting


FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c  -O0  (test for excess  
errors)


do you think this is likely to be:
1. some problem in gmp or mpfr,
2. some problem in my build of gmp and/or mpfr, that wouldn't occur  
if I'd built it in some other (unspecified) way,
3. some problem in my existing system configuration, maybe I already  
have a gmp installed that is somehow conflicting, or

4. a well-known but not serious bug in GCC's Darwin port?

It turns out the answer is 4, at least I think it is.

  So, we should fix the external library, or, in the worst case,  
declare that external library beyond salvage.


In contrast, as I understand it, Ian's perturbed about the idea of  
having an external library at all.


I don't think Ian would object to an external library that users  
could always find easily, that always built cleanly, that didn't have  
bugs...  but such a library doesn't exist.




smime.p7s
Description: S/MIME cryptographic signature

Re: build failure, GMP not available

2006-10-31 Thread Geoffrey Keating

Greg Schafer <[EMAIL PROTECTED]> writes:

> Mark Mitchell wrote:
> 
> > I don't believe there's a serious problem with the concept, as long as 
> > "./configure; make; make install" for GMP DTRT.  If you can do it for 
> > GCC, you can do it for a library it uses too.
> 
> Just another data point.
> 
> I tried building GMP on an i686-pc-linux-gnu Ubuntu system (but running on
> AMD64 hardware). The GMP configure script is apparently too smart for its
> own good because it detected my "build system" as x86_64-pc-linux-gnu and
> configure failed. I had to pass --build=i686-linux to get configure to
> complete. Yes, I should probably send a problem report to the GMP dev's..

I had the same problem on my powerpc-darwin system; the first build of
GMP built a GMP for the 64-bit ABI, which is useless for building GCC.

Re: build failure, GMP not available

2006-10-31 Thread Greg Schafer

Mark Mitchell wrote:

> I don't believe there's a serious problem with the concept, as long as 
> "./configure; make; make install" for GMP DTRT.  If you can do it for 
> GCC, you can do it for a library it uses too.

Just another data point.

I tried building GMP on an i686-pc-linux-gnu Ubuntu system (but running on
AMD64 hardware). The GMP configure script is apparently too smart for its
own good because it detected my "build system" as x86_64-pc-linux-gnu and
configure failed. I had to pass --build=i686-linux to get configure to
complete. Yes, I should probably send a problem report to the GMP dev's..

Regards
Greg
-- 
http://www.diy-linux.org/

Re: build failure, GMP not available

2006-10-31 Thread Gabriel Dos Reis

Joe Buck <[EMAIL PROTECTED]> writes:

[...]

| We do want to make it as easy as we can make it to allow non-gurus to
| build from source, because we'll get a lot more testing that way.  That
| said, I agree that an automatic download is inappropriate.
| 
| However, if we detect at configure time that GMP isn't present, it
| would be good if the error message printed out enough information
| to tell the user where s/he can download a working version.  We'll
| save everyone time that way.

Fully agreed.

-- Gaby

Re: build failure, GMP not available

2006-10-31 Thread Paul Brook

> Because gcc is the first step in bringing up a new system.  Having
> complex sets of dependencies makes people's lives harder.  I'm sure
> we've all had the unpleasant experience of trying to build something
> from the net only to discover that we had to build five other things
> first. 

In my experience the first thing you do bringing up a new system is build a 
cross compiler and use that to build glibc and coreutils/busybox. This is all 
done on an established host that has gmp/mpfr ported to it.
Bootstrapping a native compiler comes quite late in system bringup, and only 
happens at all on server/workstation-class hardware.

> > > I think that if we stick with our current approach, we will have a lot
> > > of bug reports and dissatisfied users when gcc 4.3 is released.
> >
> > I'd argue that the minority of people who are building from source
> > should not be our primary concern.  Obviously, all other things being
> > equal, we should try to make that easy -- but if we can deliver a
> > better compiler (as Kaveh has already shown we can with his patch
> > series), then we should prioritize that.  For those that want to build
> > from source, we should provide good documentation, and clear
> > instructions as to where to find what they need, but we should assume
> > they can follow complicated instructions -- since the process is
> > already complicated.
>
> I disagree: the process of building gcc from a release (as opposed to
> building the development version of gcc) really isn't complicated.
> The only remotely non-standard thing that is required is GNU make.
> Given that, all you need to do is "SRCDIR/configure; make".
> Admittedly, people often get even that simple instruction wrong.  But
> it is easy to explain what to do.

Last time I tried that it didn't work anyway because it got --enable-__atexit 
wrong.

Paul

Re: build failure, GMP not available

2006-10-31 Thread Joe Buck

On Mon, Oct 30, 2006 at 10:07:39PM -0800, Mark Mitchell wrote:
> I don't believe there's a serious problem with the concept, as long as 
> "./configure; make; make install" for GMP DTRT.  If you can do it for 
> GCC, you can do it for a library it uses too.
> 
> I would strongly oppose downloading stuff during the build process. 
> We're not in the apt-get business; we can leave that to the GNU/Linux 
> distributions, the Cygwin distributors, etc.  If you want to build a KDE 
> application, you have to first build/download the KDE libraries; why 
> should GCC be different?

We do want to make it as easy as we can make it to allow non-gurus to
build from source, because we'll get a lot more testing that way.  That
said, I agree that an automatic download is inappropriate.

However, if we detect at configure time that GMP isn't present, it
would be good if the error message printed out enough information
to tell the user where s/he can download a working version.  We'll
save everyone time that way.

Re: build failure, GMP not available


Geoffrey Keating wrote:

OK, I agree: a native compiler, with no special options, isn't too 
hard.  I don't think typing that sequence twice would be too hard 
either, though. :-)


For something that's not too hard, it's sure causing me a lot of trouble...


But, the trouble you're having is not because you have to build an 
external library; it's because the external library you're building 
doesn't work on your system, or, at least, doesn't work with obvious 
default build options.  So, we should fix the external library, or, in 
the worst case, declare that external library beyond salvage.


In contrast, as I understand it, Ian's perturbed about the idea of 
having an external library at all.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: build failure, GMP not available

2006-10-31 Thread Shantonu Sen


Ah, your "&&" did not indicate which command was failing.

You can work around the issue with CFLAGS="-fno-common", which you  
probably want to do anyway if this code is ever linked in statically  
into libgfortran or something. However, it's just the test code that  
has this issue.


You can also work around this by setting RANLIB="ranlib -c", so that  
the calling_convention_* symbols get put in the archive table of  
contents so that the Darwin linker loads the archive member on-demand  
from libtests.a


Shantonu

On Oct 30, 2006, at 5:42 PM, Geoffrey Keating wrote:



On 30/10/2006, at 5:31 PM, Shantonu Sen wrote:

For what it's worth, I did a build on Mac OS X for Intel 10.4.8  
last week, and had no problems building GMP 4.2.1 and mprf-2.2.0,  
with no special --target options. Maybe you have an old version of  
gmp in your default linker search path causing bad things to  
happen. I think if it's failing for you, you're doing something  
wrong. I see no evidence that either GMP or mainline GCC is broken  
on i686-darwin


Did you run 'make check'?  Did you get the line that caused the  
error I saw?

Re: build failure, GMP not available

2006-10-31 Thread Steven Bosscher


On 10/31/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:

This question is not related to the apparent
instability and thus
low quality of GMP/MPFR at all.


This is the second time I see someone complain about GMP/MPFR
instability. What is this complaint based on?  We've used GMP in g95
and later gfortran since the project incarnation 7 years ago, and as
far as I know we've never had to change anything for reasons of
instability. In fact, AFAIK we still had source compatibility when we
moved from GMP3 to GMP4. Is there some bug report / web page somewhere
that describes the instability problems you folks apparently have on
Macs?

Gr.
Steven

Re: build failure, GMP not available

2006-10-31 Thread Marcin Dalecki

On 2006-10-31, at 01:59, Daniel Berlin wrote:

On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:

On 2006-10-30, at 21:37, Daniel Berlin wrote:
> Honestly, I don't know any mac people who *don't* use either  
fink or
> macports to install unix software when possible, because pretty  
much

> everything has required some small patch or another.

I guess you are joking?

I guess you think the vast majority of mac users who install unix
software do it manually?

This is not related to your first statement at all. I just wanted to  
make you aware
that there are actually people out there, who don't use fink or  
macports at all.
They tend to don't won't to get into the hell of apt-get or yum  
cycles starting

every working day. They tend to like to have a reproducible dependable
*stable* working environment not infected with unstable buggy software,
which can be used as a shipment basis for customers too.

do you also think more than 1% of people still use lynx? (This is a
trick question, I know the actual stats for the top 10 websites :P)

I don't care. This question is not related to the apparent  
instability and thus

low quality of GMP/MPFR at all.

Marcin Dalecki

Re: build failure, GMP not available

2006-10-31 Thread Geoffrey Keating



On 31/10/2006, at 12:28 AM, Mark Mitchell wrote:

Ian Lance Taylor wrote:

Mark Mitchell <[EMAIL PROTECTED]> writes:

I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, etc.


I can't speak for, say, Google, or even Apple, but I don't plan to  
have GMP (or, therefore, MFPR) shared libraries or .a files ship with  
Mac OS; the library is not ABI-stable and .a files are not worth the  
effort, and anyway by the time they shipped they would probably be  
out of date.  You'll need to get them separately from somewhere.   
Maybe 'somewhere' will be gcc.gnu.org, if I find the time to package  
them up nicely.



I disagree: the process of building gcc from a release (as opposed to
building the development version of gcc) really isn't complicated.
The only remotely non-standard thing that is required is GNU make.
Given that, all you need to do is "SRCDIR/configure; make".


OK, I agree: a native compiler, with no special options, isn't too  
hard.  I don't think typing that sequence twice would be too hard  
either, though. :-)


For something that's not too hard, it's sure causing me a lot of  
trouble...




smime.p7s
Description: S/MIME cryptographic signature

Re: build failure, GMP not available

2006-10-31 Thread Paolo Bonzini



I wouldn't object to that.  It's a bit more build-system complexity, but 
if it makes it easier for people, then it's worth it.


Actually, since we are at it, I would like to have toplevel configure 
automatically symlink "foo-1.2.3" to "foo".  This way, untarring 
gmp/mpfr (and maybe also bison/texinfo/whatever) would magically work.


I have not done this until now because binutils, gdb and other things 
using the gcc/src build system would not work in this scheme. :-(


Paolo

Re: build failure, GMP not available

2006-10-31 Thread Paolo Bonzini




There is also "fink" (fink.sf.net), which i believe would provide a
new enough gmp, but i am not positive.


Yes, fink packages "gmp gmp-shlibs libmpfr1-dev libmpfr1-shlibs" provide 
all that is needed.


Paolo

Re: build failure, GMP not available


Ian Lance Taylor wrote:

Mark Mitchell <[EMAIL PROTECTED]> writes:


I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, etc.  If you want to
build a KDE application, you have to first build/download the KDE
libraries; why should GCC be different?


Because gcc is the first step in bringing up a new system. 


I don't find this as persuasive as I used to.  There aren't very many 
new host systems, and when there are, you get started with a cross compiler.



I disagree: the process of building gcc from a release (as opposed to
building the development version of gcc) really isn't complicated.
The only remotely non-standard thing that is required is GNU make.
Given that, all you need to do is "SRCDIR/configure; make".


OK, I agree: a native compiler, with no special options, isn't too hard. 
 I don't think typing that sequence twice would be too hard either, 
though. :-)



I'm certainly not saying that we should pull out GMP and MPFR.  But I
am saying that we need to do much much better about making it easy for
people to build gcc. 


I agree; I just don't think an external library is the problem.  For 
example, the unfortunate tendency of broken C++ compilers to manifest as 
autoconf errors about "run-time test after link-time failure" (that's 
not the right error) in libstdc++ builds confused me a bunch.  The fact 
that you can pass configure options that are silently ignored is a trap. 
 I'm sure we don't have good documentation for all of the configuration 
options we do have.  The way the libgcc Makefiles get constructed from 
shell scripts and the use of recursive make to invoke them confuses me, 
and the fact that "make" at the top level does things differently than 
"make" in the gcc/ directory also confuses me.  IIRC, --with-cpu= works 
on some systems, but not others.


In other words, the situation that you're on a GNU/Linux system, and 
have to  type "configure; make; make install" several times for several 
packages to GCC doesn't seem too bad to me.  What seems bad, and 
off-putting to newcomers interested in working on the source, is that as 
soon as you get past that point it all gets very tangled very quickly.


But, that's just me.  I wouldn't try to stop anybody from adding 
--with-gmp=http://www.gmp.org/gmp-7.3.tar.gz to the build system, even 
though I'd find it personally frightening. :-)


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: build failure, GMP not available


Steven Bosscher wrote:

On 30 Oct 2006 22:56:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:


I'm certainly not saying that we should pull out GMP and MPFR.  But I
am saying that we need to do much much better about making it easy for
people to build gcc.


Can't we just make it so that, if gmp/  amd mpfr/ directories exist in
the toplevel, they are built along with GCC?  I don't mean actually
including gmp and mpfr in the gcc SVN repo, but just making it
possible to build them when someone unpacks gmp/mpfr tarballs in the
toplevel dir.


I wouldn't object to that.  It's a bit more build-system complexity, but 
if it makes it easier for people, then it's worth it.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: build failure, GMP not available

2006-10-30 Thread Steven Bosscher


On 30 Oct 2006 22:56:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:


I'm certainly not saying that we should pull out GMP and MPFR.  But I
am saying that we need to do much much better about making it easy for
people to build gcc.


Can't we just make it so that, if gmp/  amd mpfr/ directories exist in
the toplevel, they are built along with GCC?  I don't mean actually
including gmp and mpfr in the gcc SVN repo, but just making it
possible to build them when someone unpacks gmp/mpfr tarballs in the
toplevel dir.

Gr.
Steven

Re: build failure, GMP not available

2006-10-30 Thread Ian Lance Taylor

Mark Mitchell <[EMAIL PROTECTED]> writes:

> I would strongly oppose downloading stuff during the build
> process. We're not in the apt-get business; we can leave that to the
> GNU/Linux distributions, the Cygwin distributors, etc.  If you want to
> build a KDE application, you have to first build/download the KDE
> libraries; why should GCC be different?

Because gcc is the first step in bringing up a new system.  Having
complex sets of dependencies makes people's lives harder.  I'm sure
we've all had the unpleasant experience of trying to build something
from the net only to discover that we had to build five other things
first.  It sucks.

If we were requiring libraries which were normally installed, I
wouldn't mind so much.  But I had to download and build my own copy of
MPFR for Fedora Core 5, which is a recent and popular distribution
(GMP, at least, was already installed).

> > I think that if we stick with our current approach, we will have a lot
> > of bug reports and dissatisfied users when gcc 4.3 is released.
> 
> I'd argue that the minority of people who are building from source
> should not be our primary concern.  Obviously, all other things being
> equal, we should try to make that easy -- but if we can deliver a
> better compiler (as Kaveh has already shown we can with his patch
> series), then we should prioritize that.  For those that want to build
> from source, we should provide good documentation, and clear
> instructions as to where to find what they need, but we should assume
> they can follow complicated instructions -- since the process is
> already complicated.

I disagree: the process of building gcc from a release (as opposed to
building the development version of gcc) really isn't complicated.
The only remotely non-standard thing that is required is GNU make.
Given that, all you need to do is "SRCDIR/configure; make".
Admittedly, people often get even that simple instruction wrong.  But
it is easy to explain what to do.

I'm certainly not saying that we should pull out GMP and MPFR.  But I
am saying that we need to do much much better about making it easy for
people to build gcc.  Sure, the people who build gcc aren't our
primary concern.  But they are a major concern, if only because those
are the people who are our future developers.

Ian

Re: build failure, GMP not available

2006-10-30 Thread Mark Mitchell


Ian Lance Taylor wrote:


I'm not sure I entirely agree with Mark's reasoning.  It's true that
we've always required a big set of tools to do development with gcc.
And it's true that we require GNU make to be installed and working in
order to build gcc.  But this is the first time that we've ever
required a non-standard library to be installed before J. Random User
can build gcc.  And plenty of people do try to build gcc themselves,
as can be seen on gcc-help.


I don't believe there's a serious problem with the concept, as long as 
"./configure; make; make install" for GMP DTRT.  If you can do it for 
GCC, you can do it for a library it uses too.


I would strongly oppose downloading stuff during the build process. 
We're not in the apt-get business; we can leave that to the GNU/Linux 
distributions, the Cygwin distributors, etc.  If you want to build a KDE 
application, you have to first build/download the KDE libraries; why 
should GCC be different?



I think that if we stick with our current approach, we will have a lot
of bug reports and dissatisfied users when gcc 4.3 is released.


I'd argue that the minority of people who are building from source 
should not be our primary concern.  Obviously, all other things being 
equal, we should try to make that easy -- but if we can deliver a better 
compiler (as Kaveh has already shown we can with his patch series), then 
we should prioritize that.  For those that want to build from source, we 
should provide good documentation, and clear instructions as to where to 
find what they need, but we should assume they can follow complicated 
instructions -- since the process is already complicated.


I do think it's important that we make sure there's a readily buildable 
GMP available, including one that works on OS X, in time for 4.3.  We 
should provide a tarball for it from gcc.gnu.org, if there isn't a 
suitable GMP release by then.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: build failure, GMP not available



On 30/10/2006, at 5:31 PM, Shantonu Sen wrote:

For what it's worth, I did a build on Mac OS X for Intel 10.4.8 last  
week, and had no problems building GMP 4.2.1 and mprf-2.2.0, with no  
special --target options. Maybe you have an old version of gmp in  
your default linker search path causing bad things to happen. I  
think if it's failing for you, you're doing something wrong. I see  
no evidence that either GMP or mainline GCC is broken on i686-darwin


Did you run 'make check'?  Did you get the line that caused the error  
I saw?




smime.p7s
Description: S/MIME cryptographic signature

Re: build failure, GMP not available

2006-10-30 Thread Shantonu Sen

For what it's worth, I did a build on Mac OS X for Intel 10.4.8 last
week, and had no problems building GMP 4.2.1 and mprf-2.2.0, with no
special --target options. Maybe you have an old version of gmp in your
default linker search path causing bad things to happen. I think if
it's failing for you, you're doing something wrong. I see no evidence
that either GMP or mainline GCC is broken on i686-darwin

I submitted the results of that build to gcc-testresults.

Shantonu

On Oct 30, 2006, at 11:49 AM, Geoffrey Keating wrote:

On 30/10/2006, at 10:34 AM, Daniel Berlin wrote:

4. Are you aware that the GMP home page says

[2006-05-04] GMP does not build on MacInteltosh machines. No fix
planned for GMP 4.x.

and indeed it does not appear to build correctly when configured on
my MacBook Pro?

Errr, well,
I have installed the version from macports on my macbook pro, and
it works fine.

No new regressions in the gcc testsuite since the GMP patches.

I don't know what "macports" is. When I download gmp-4.2.1 from ftp.gnu.org
, the official GNU site, and run 'configure && make && make check',
I get:

gcc -m32 -O2 -fomit-frame-pointer -mtune=pentium3 -march=pentium3 -o
t-bswap t-bswap.o ./.libs/libtests.a /Volumes/Data/build/
gmp-4.2.1/.libs/libgmp.a ../.libs/libgmp.a

/usr/bin/ld_classic: Undefined symbols:
_calling_conventions_ebp
_calling_conventions_ebx
_calling_conventions_edi
_calling_conventions_eflags
_calling_conventions_esi
_calling_conventions_fenv
_calling_conventions_retaddr
_calling_conventions_save_ebp
_calling_conventions_save_ebx
_calling_conventions_save_edi
_calling_conventions_save_esi

which I presume is the problem referred to.

Googling for 'macports gmp' leads me to which suggests to me that maybe I should say 'configure --
host=none-apple-darwin'. I'll try that.

Because of the severe nature of this problem (everything doesn't
build, multiple hosts affected), I'd like you to consider backing
out

this patch until the problems are fixed. I'll work on a patch which
just disables the check for Darwin.

Uh, what?

In this case, I have no idea what problems you are experiencing, as
the version of GMP/MPFR required works fine on macbook pro, AFAICT.

Do you see this error when you run 'make check'?

It's actually about time we got to using GMP in the middle end, and I
don't believe reverting a patch because some non-primary platforms
have a few pains here and there initially is the best course of
action.

I agree that it's nice to use GMP in the middle-end, but it raises
significant portability issues. It looks like there are workarounds
for the x86-darwin problem, but surely there will be other problems
on other platforms. My greatest concern is bootstrapping.

Also, although I experience no regressions, i'll point out that there
is no automated tested for macintel darwin that posts to
gcc-testresults, which does not bode well for something you would
like

to be a primary platform.

You are not seeing any posts because there has never been a
successful build in the tester's environment. Guess what the
current problem is.

Re: build failure, GMP not available

2006-10-30 Thread Ian Lance Taylor

"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:

> On Mon, 30 Oct 2006, Geoffrey Keating wrote:
> 
> > 5. Are you aware that the GMP home page says
> >
> > Note that we chose not to work around all new GCC bugs in this
> > release. Never forget to do  make check  after building the library
> > to make likely it was not miscompiled!
> >
> > and therefore this library needs to be part of the bootstrap, not
> > built separately?
> 
> One more thing, I initially went down the road of including the GMP/MPFR
> sources in the gcc tree and building them as part of the bootstrap
> process.  But the consensus was not to do that:
> 
> http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html

I'm not sure I entirely agree with Mark's reasoning.  It's true that
we've always required a big set of tools to do development with gcc.
And it's true that we require GNU make to be installed and working in
order to build gcc.  But this is the first time that we've ever
required a non-standard library to be installed before J. Random User
can build gcc.  And plenty of people do try to build gcc themselves,
as can be seen on gcc-help.

If we are going to require these libraries, and we are not going to
include them directly in the gcc sources, then I think it is incumbent
on us to make the build procedure much much smarter.  For example, if
sufficiently new versions of the libraries can not be found, then
perhaps the build procedure should actually download the versions from
a known good site (e.g., gcc.gnu.org), unpack them, and build them.  I
don't care whether this is done at configure time or make time.  If
the code can not be downloaded, then I think the build procedure needs
to give an extensive and clear error message which includes a
description of where the sources can be found, how to build them, and
how to run configure correctly.

I think that if we stick with our current approach, we will have a lot
of bug reports and dissatisfied users when gcc 4.3 is released.

Ian

Re: build failure, GMP not available

2006-10-30 Thread Mike Stump


On Oct 30, 2006, at 4:55 PM, Mike Stump wrote:

3 out of 4 hunks FAILED -- saving rejects to file tests/texp2.c.rej

?


I'm informed that --dry-run is broken...  Very odd, so unfortunate.

Re: build failure, GMP not available

2006-10-30 Thread Andrew Pinski

> 
> On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> >
> > On 2006-10-30, at 21:37, Daniel Berlin wrote:
> > > Honestly, I don't know any mac people who *don't* use either fink or
> > > macports to install unix software when possible, because pretty much
> > > everything has required some small patch or another.
> >
> > I guess you are joking?
> 
> I guess you think the vast majority of mac users who install unix
> software do it manually?

And if they do, they hate Apple anyways for not including their favorite
library or program already so they should know what they are doing.

-- Pinski

Re: build failure, GMP not available

2006-10-30 Thread Daniel Berlin

On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:

On 2006-10-30, at 21:37, Daniel Berlin wrote:
> Honestly, I don't know any mac people who *don't* use either fink or
> macports to install unix software when possible, because pretty much
> everything has required some small patch or another.

I guess you are joking?

I guess you think the vast majority of mac users who install unix
software do it manually?

do you also think more than 1% of people still use lynx? (This is a
trick question, I know the actual stats for the top 10 websites :P)

Marcin Dalecki

Re: build failure, GMP not available

2006-10-30 Thread Joseph S. Myers

On Mon, 30 Oct 2006, Mike Stump wrote:

> mrs $ patch -p1 --dry-run < ~/Desktop/mpfr-2.2.0-cumulative.patch

Because the patch is the concatenation of 16 successive fixes for 
individual bugs (so contains more than one diff to some files), --dry-run 
won't work with it.  The patch should apply fine without --dry-run.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: build failure, GMP not available

2006-10-30 Thread Mike Stump


On Oct 30, 2006, at 1:55 PM, Kaveh R. GHAZI wrote:

Copies of the correct sources were put in:
ftp://gcc.gnu.org/pub/gcc/infrastructure/


mrs $ bunzip2 ?  :-(  I just installed the broken one and didn't worry about it.   
I'm sure it'll come back to bite me.  I wish the mpfr people could be  
swayed to put out a `fixed' release, say 2.2.1.  Requiring the  
patching of a download is, uhm, so old-skool.

Re: build failure, GMP not available

2006-10-30 Thread Marcin Dalecki



On 2006-10-30, at 21:37, Daniel Berlin wrote:

Honestly, I don't know any mac people who *don't* use either fink or
macports to install unix software when possible, because pretty much
everything has required some small patch or another.


I guess you are joking?

Marcin Dalecki

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Geoffrey Keating wrote:

> > One more thing, I initially went down the road of including the GMP/
> > MPFR
> > sources in the gcc tree and building them as part of the bootstrap
> > process.  But the consensus was not to do that:
> >
> > http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html
>
> I think the problem is that Mark also said
>
> > I do think we should do is provide a known-good version (whether
> > via a tag in some version control system, or via a tarball) of
> > these libraries so that people can easily get versions that work.
>
> and this is the part that didn't work; it's not good enough to think
> that a good version might exist, you need to know what it actually
> is, because knowing what it is might change your opinion on whether
> it's good...

Well, the correct versions were documented in
http://gcc.gnu.org/install/prerequisites.html

Copies of the correct sources were put in:
ftp://gcc.gnu.org/pub/gcc/infrastructure/

Where it broke down for you seems to be in the installation instructions
that accompany the tarballs.  But I don't have any control over those, the
GMP/MPFR maintainers do.

Do we have a GCC FAQ somewhere?  Maybe we can add GMP/MPFR build problems
and solutions there.  You can add your experiences to that collection.

I'm sorry you've had trouble, hopefully all this is a one-time thing that
doesn't cause too much grief for everyone.  Then we can all get back to
making GCC better. :-)

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Geoffrey Keating wrote:

> > I'd like to point out that the powerpc-darwin reports we were getting
> > from the regression tester prior to this requirement were not
> > including gfortran results:
> > http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01062.html
> >
> > One of the benefits IMHO of requiring gmp/mpfr is that fortran how
> > always works regardless.  I hope once you get these libraries
> > installed that you add back fortran to the languages tested on both
> > x86 and powerpc.
>
> My policy is that I do not add or remove languages (or multilibs,
> testcases, patches, libraries, configure flags, or anything else).
> What gets built and tested is '.../configure && make'.  That way (a)  I
> know I'm testing the default which is presumably what most people use
> and (b) I don't have to deal with time-consuming arguments about what
> should or should not be in the tester.

Understood.  However once you get gmp/mpfr installed and pass in the
appropriate with-gmp= directory, fortran should be on by default since I
took out the "need_gmp" checks in gcc-4.3.  If you avoid passing an
--enable-languages configure flag that takes it out, it'll be in the
default.  Older releases may also simply work if you merely tell gcc
where to find gmp/mpfr.

I don't know if telling older gcc release where to find gmp/mpfr violates
your "policy".  But since you have to do it for 4.3, you can be excused
for "cheating" a little. :-)

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: build failure, GMP not available

One more thing, I initially went down the road of including the GMP/ 
MPFR

sources in the gcc tree and building them as part of the bootstrap
process.  But the consensus was not to do that:

http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html


I think the problem is that Mark also said

I do think we should do is provide a known-good version (whether  
via a tag in some version control system, or via a tarball) of  
these libraries so that people can easily get versions that work.


and this is the part that didn't work; it's not good enough to think  
that a good version might exist, you need to know what it actually  
is, because knowing what it is might change your opinion on whether  
it's good...




smime.p7s
Description: S/MIME cryptographic signature

Re: build failure, GMP not available



On 30/10/2006, at 1:24 PM, Kaveh R. GHAZI wrote:


On Mon, 30 Oct 2006, Geoffrey Keating wrote:

Also, although I experience no regressions, i'll point out that  
there

is no automated tested for macintel darwin that posts to
gcc-testresults, which does not bode well for something you would  
like

to be a primary platform.


You are not seeing any posts because there has never been a  
successful
build in the tester's environment.  Guess what the current problem  
is.


I'd like to point out that the powerpc-darwin reports we were  
getting from

the regression tester prior to this requirement were not including
gfortran results:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01062.html

One of the benefits IMHO of requiring gmp/mpfr is that fortran how  
always
works regardless.  I hope once you get these libraries installed  
that you

add back fortran to the languages tested on both x86 and powerpc.


My policy is that I do not add or remove languages (or multilibs,  
testcases, patches, libraries, configure flags, or anything else).   
What gets built and tested is '.../configure && make'.  That way (a)  
I know I'm testing the default which is presumably what most people  
use and (b) I don't have to deal with time-consuming arguments about  
what should or should not be in the tester.

smime.p7s
Description: S/MIME cryptographic signature

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Geoffrey Keating wrote:

> > Also, although I experience no regressions, i'll point out that there
> > is no automated tested for macintel darwin that posts to
> > gcc-testresults, which does not bode well for something you would like
> > to be a primary platform.
>
> You are not seeing any posts because there has never been a successful
> build in the tester's environment.  Guess what the current problem is.

I'd like to point out that the powerpc-darwin reports we were getting from
the regression tester prior to this requirement were not including
gfortran results:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01062.html

One of the benefits IMHO of requiring gmp/mpfr is that fortran how always
works regardless.  I hope once you get these libraries installed that you
add back fortran to the languages tested on both x86 and powerpc.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Geoffrey Keating wrote:

> 5. Are you aware that the GMP home page says
>
> Note that we chose not to work around all new GCC bugs in this
> release. Never forget to do  make check  after building the library
> to make likely it was not miscompiled!
>
> and therefore this library needs to be part of the bootstrap, not
> built separately?

One more thing, I initially went down the road of including the GMP/MPFR
sources in the gcc tree and building them as part of the bootstrap
process.  But the consensus was not to do that:

http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: build failure, GMP not available

On Mon, 30 Oct 2006, Geoffrey Keating wrote:

> Hi Kaveh,
>
> Since your patch
>
> 
> r117933 | ghazi | 2006-10-21 06:58:13 -0700 (Sat, 21 Oct 2006) | 16
> lines
>
>  * configure.in: Require GMP-4.1+ and MPFR-2.2+.  Don't check
>  need_gmp anymore.
>
> I'm getting
>
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2+.  Try
> the --with-gmp and/or --with-mpfr options.

Hi Geoff,

I believe most of your questions were already answered.  But I'll try and
fill in some additional info.

> 1. Is this intentional?
> 2. Is it supposed to apply to the host, the target, or both?
> 3. If it's intentional, what is the list of platforms that you
> intended to prevent building, that is, platforms which GCC used to
> support but on which GMP or MPFR does not build?

It should be possible to build gmp and mpfr on (at least) all the primary
and secondary platforms.  Before installing my patch, I did a search for
testsuite posts with gfortran results on the major systems.  I assumed
that I could use gfortran results as a proxy for gmp/mpfr working since
that language already requires those libraries.  See:
http://gcc.gnu.org/ml/gcc/2006-10/msg00224.html

Note that x86-darwin was among those results.  In addition to my posting,
Francois posted a followup with several more platforms, and the MPFR page
in my posting lists many more platforms where it is supposed to work.

> 4. Are you aware that the GMP home page says
>
> [2006-05-04] GMP does not build on MacInteltosh machines. No fix
> planned for GMP 4.x.
>
> and indeed it does not appear to build correctly when configured on
> my MacBook Pro?
>
> 5. Are you aware that the GMP home page says
>
> Note that we chose not to work around all new GCC bugs in this
> release. Never forget to do  make check  after building the library
> to make likely it was not miscompiled!
>
> and therefore this library needs to be part of the bootstrap, not
> built separately?

As was noted, you should be able to build GMP with generic C sources as
opposed to optimized assembly using the "none" CPU type.

> 6. The regression tester does actually have GMP installed, but it is,
> not in /usr/local.  Should this code be searching for GMP and mpfr in
> more places if it is not found?

We already have --with-* options so you can specify the directory where
you have gmp and/or mpfr installed.  I don't think we need to probe
additional directories automatically, that list could get rather large
pretty fast and introduce unexpected wierdness if unintended stuff gets
sucked in.

>
> Because of the severe nature of this problem (everything doesn't
> build, multiple hosts affected), I'd like you to consider backing out
> this patch until the problems are fixed.  I'll work on a patch which
> just disables the check for Darwin.

As was noted, if you disable the check, you'll simply get a build failure
in the middle-end which now uses gmp/mpfr.  Let's see if you can get these
libraries installed before going down that road.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: build failure, GMP not available

2006-10-30 Thread Daniel Berlin

On 10/30/06, Geoffrey Keating <[EMAIL PROTECTED]> wrote:

On 30/10/2006, at 10:34 AM, Daniel Berlin wrote:

>> 4. Are you aware that the GMP home page says
>>
>> [2006-05-04] GMP does not build on MacInteltosh machines. No fix
>> planned for GMP 4.x.
>>
>> and indeed it does not appear to build correctly when configured on
>> my MacBook Pro?
>>
> Errr, well,
> I have installed the version from macports on my macbook pro, and
> it works fine.
> No new regressions in the gcc testsuite since the GMP patches.

I don't know what "macports" is.

It (http://www.macports.org) is formerly known as darwinports, and is
a freebsd port style system for Darwin.

There is also "fink" (fink.sf.net), which i believe would provide a
new enough gmp, but i am not positive.

Honestly, I don't know any mac people who *don't* use either fink or
macports to install unix software when possible, because pretty much
everything has required some small patch or another.

When I download gmp-4.2.1 from
ftp.gnu.org, the official GNU site, and run 'configure && make &&
make check', I get:

Googling for 'macports gmp' leads me to 
which suggests to me that maybe I should say 'configure --host=none-
apple-darwin'.  I'll try that.

Yup, that should be what macports (the port system formerly known as
darwinports)

>> Because of the severe nature of this problem (everything doesn't
>> build, multiple hosts affected), I'd like you to consider backing out
>> this patch until the problems are fixed.  I'll work on a patch which
>> just disables the check for Darwin.
> Uh, what?
>
> In this case, I have no idea what problems you are experiencing, as
> the version of GMP/MPFR required works fine on macbook pro, AFAICT.

Do you see this error when you run 'make check'?

I just ran port install gmp using macports, which presumably just ran
make and make install. The resulting version has worked fine for me,
so i could not tell you.

> It's actually about time we got to using GMP in the middle end, and I
> don't believe reverting a patch because some non-primary platforms
> have a few pains here and there initially is the best course of
> action.

I agree that it's nice to use GMP in the middle-end, but it raises
significant portability issues.  It looks like there are workarounds
for the x86-darwin problem, but surely there will be other problems
on other platforms.  My greatest concern is bootstrapping.

While i'm sure you are correct that we will have gmp problems on other
platforms, I also believe this is true of any dependency we add.
There are always problems with some library on some platform.  At some
point we have to just say "look, we'll fix the bugs we find and submit
the patches upstream" or we'll never be able to add any
*dependencies*, just a bunch of "optional" stuff that increases the
size of the support matrix (by having "with" and "without" versions).

Thus, if we believe that the benefits provided by GMP are worth it, we
should do it anyway and just fix the bugs.  The consensus of people
was that GMP was worth it (and i agree, from my understanding of the
issues), so here we are, fixing the bugs!

> Also, although I experience no regressions, i'll point out that there
> is no automated tested for macintel darwin that posts to
> gcc-testresults, which does not bode well for something you would like
> to be a primary platform.

You are not seeing any posts because there has never been a
successful build in the tester's environment.  Guess what the current
problem is.

Uh, you proposed it as a primary platform weeks before the switch to
turn on GMP occurred, so while i can understand it being the current
problem, that doesn't explain why it wasn't happening before then.

Honestly, I believe it should be a requirement of any primary platform
that prior to becoming a primary platform, regular testresults are
posted to gcc-testresults (regardless of whether they are done by
machines or humans)

Re: build failure, GMP not available