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 useful for sophisticated > static analysis) or the Libtool Dynamic Loader, which might be useful > also, for example if the compiler needs to generate some specialized > (w.r.t. to the compiled source code) code. Maybe my position is > unusual, but I believe that more and more external libraries or > softwares will become required or useful to GCC.
If we can link against fixed, stable, distributed versions of the supporting libraries, then I think I agree with you. Or, alternatively, if the supporting libraries are optional. The problems we're seeing with MPFR is that we seem to require a changing, undistributed version. I don't have a problem with requiring changing versions of tools which are only needed by developers, such as autoconf. I think it is problematic to require shifting versions of tools which are needed by everybody who builds gcc, though of course I agree that is a much smaller set of people than the set of people who use gcc. 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 external library which is not in the tree, we should not be at the bleeding edge of that library. I also want to note that using external libraries is going to give us problems reproducing bugs, when different users/distributors use different versions of those libraries. At the very least we need to report the version number of each external library in gcc --version. Ian
