This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

On Mon, 27 Oct 2008, Richard Guenther wrote:

> On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
> <> wrote:
> > On Sun, 26 Oct 2008, David Edelsohn wrote:
> >
> >> Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
> >> by g++, this effectively requires that libgmpxx must be a shared
> >> library.  libgmp
> >
> > I hope the Graphite people are working on fixing this for 4.4.  As I said
> > in <> (following
> > Ian's slides), libstdc++ should be statically linked into cc1 by default -
> > which probably means that if static libgmpxx is available then it should
> > be used.  I'm also concerned that we still don't have any documentation in
> > install.texi concerning these libraries and pointing to suitable release
> > tarballs of them in the infrastructure directory - we're nearly two months
> > into Stage 3 and these libraries should be subject to much the same
> > development stage rules as in-tree optimizers with the versions documented
> > to be used and associated configure checks changing only to update to new
> > bug-fix minor releases, not major feature releases, while in Stage 3.
> I think we are still waiting for the final ppl release, but otherwise
> I agree that
> instructions and tarballs should be provided rather yesterday than tomorrow.
> I don't necessarily agree with statically linking libstdc++ into cc1 - do you
> expect problems with linking dynamically?  Static libraries for libgmpxx or
> ppl or cloog are usually not available due to size and their libstdc++
> requirement.

The first and most important step is to support linking with static 
versions of ppl, cloog, gmp, gmpxx, mpfr.  Linking with separately built 
static versions of GMP and MPFR is clearly something widely done as where 
OS versions are available at all they may often be too old and this should 
work just as well for the other libraries, and using static versions 
avoids all problems with the compiler binaries depending on shared 
libraries in nonstandard paths.

The comments above suggest this is broken for the new libraries used by 
Graphite - presumably because of not linking with -lstdc++ so it can only 
be found through shared library dependencies, though they don't specify 
this.  If that is the case then the configure support needs to know to add 
-lstdc++ when linking with these libraries using GCC.

Next is the static libstdc++ - my suggest was that *if static Cloog/PPL 
are being used* then so should static libstdc++, though this could be 
controlled with a configure option.  (One might note that the Ada 
compilers are linked with static versions of the Ada libraries by default; 
I'm sure there are cases where linking with the shared libraries would be 
safe, but the default is for the binaries not to depend on the shared 
libraries.)  Linking with static libstdc++ avoids the binaries depending 
on a shared library that again may not be a system library (especially if 
you follow the procedure some people have suggested of building cross 
compilers always with a native compiler of the same version, which may 
avoid some problems with bootstrap compiler bugs - the context in which 
it's been suggested - but would also potentially introduce dependence of 
one compiler installation on shared libraries in another).

Following that is the problem gcc-in-cxx will need to solve, of 
bootstrapping libstdc++ so each stage's compiler binaries can be linked 
with the previous stage's libstdc++ and a compiler using 
can bootstrap one using (which may also require the ability 
to build PPL in-tree in order to bootstrap it across incompatible C++ 
library ABIs).  Linking the compiler binaries with static libstdc++ 
certainly simplifies some of the bootstrap issues there.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]