On Fri, 25 May 2007, Daniel Jacobowitz wrote:
> On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
> > > I honestly don't know how to answer this question. Bootstrapping is an
> > > unrelated problem, and the compiler is not a vital runtime component
> > > of the system, so its dependencies do not need to be exceptionally
> > > robust in the way that glibc's or even libstdc++'s do.
> >
> > A compiler is a "second order" thing though: its ill behaviour sends ripples
> > through all the stuff it compiles. Suppose that an MPFR upgrade introduces
> > a
> > bug in the library and that the compiler is affected; every single program
> > compiled from now on will be potentially affected by the MPFR bug, even if
> > it
> > has nothing to do with MPFR.
>
> That just means that it's an application you care about. And now an
> upgrade of MPFR which fixes bugs will require you to rebuild the
> compiler.
>
> We could go around this in circles forever; I think that the tradeoffs
> are exactly the same as for any other application on your system, both
> pro and con.
I agree. There are pros & cons and reasonable people can arrive at
different conclusions about whether to link cc1 shared or static. If we
had a way to specify it via a configure option that would let each person
decide for themselves. So perhaps having a flag is a good idea. I don't
have an opinion on what the default should be, and I hope we can avoid a
flame war over that. :-)
However there are two existing options in the mean time:
One is build/install gmp/mpfr yourself and specify --disable-shared to
both. Then use --with-mpfr= to specify using them instead of the system's
shared versions.
The second is to drop gmp/mpfr into the top level directory and let the
bootstrap process build them. This will automatically do --disable-shared
and not install these libraries, IIRC.
CLEARLY, these aren't as easy as a configure option, but should work for
people building their own compiler distributions. If we decide to add a
top level configure option I believe that honoring it would require using
libtool to link cc1 et al. I'm not fluent in libtool at all and so I'm
not confortable enough to propose a patch.
--Kaveh
PS: A related problem with shared libraries is that currently all binaries
(xgcc, collect2, cpp, gcov, etc) are linked with gmp/mpfr, whereas only
cc1 etc (stuff containing libbackend.a) really needs to be. It's probably
harmless, but may add a few microseconds of unnecessary startup time.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
