On Mon, 27 Oct 2008, Richard Guenther wrote: > On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers > <[EMAIL PROTECTED]> 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 <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00144.html> (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 libstdc++.so.6 can bootstrap one using libstdc++.so.7 (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 [EMAIL PROTECTED]
