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
