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 <http://gmp.darwinports.com/> 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)
