This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: build failure, GMP not available
On 10/30/06, Geoffrey Keating <geoffk@apple.com> 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)