[M3devel] gmp and mpfr

[Olaf Wagner]

Quoting Jay <jayk123 at hotmail.com>:

> Thanks.
>
>  > other thoughts?
>
> Static link?
>
> I should measure the bloat.
> I accidentally statically linked to libc.a and the bloat was small,   
> I think x86 static was smaller than AMD64 dynamic.

We must not link _any_ executable completely statically, we've been
through that. Modern Unix systems all require dynamic linking, at
least for all the standard C libraries.

>   > But that would mean a full install of gcc and libraries.
>
> Really?
> Why not just gmp and mpfr and then point configure at them?
> Besides, if necessary, import them but not under gcc?
>
>  - Jay
>
>
> From: HOSKING at cs.purdue.edu
> To: m3devel at elegosoft.com
> Date: Fri, 18 Apr 2008 17:23:24 -0400
> Subject: [M3devel] gmp and mpfr
>
> I have added the necessary gmp and mpfr distributions to the   
> m3cc/gcc package.  It turns out that gcc will try to build from   
> local source if it is available in the gcc hierarchy.  Now, the only  
>  question is how to make sure that installs will put things in the   
> right place.  One option is to configure gcc to install into   
> INSTALL_ROOT from the m3cc m3makefile.  But that would mean a full   
> install of gcc and libraries.  Any other thoughts?

If we really need to have these libraries in the distribution,
we should either link them in statically or put the shared objects
into INSTALL_ROOT/lib. We could either create different packages
(that would require adding these to several scripts) or add some
special quake code to build them all as part of m3cc:

   build libgmp
   ship libgmp to INSTALL_ROOT/lib
   build mpfr
   ship mpfr to INSTALL_ROOT/lib
   configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \
     --with-gmp=INSTALL_ROOT/lib/libgmp.so
   (I don't think the argument are completely correct, but you get the idea.)
   build gcc
   ship gcc

The problem with this setup is that it wouldn't work for local builds
(without shipping), and we'd have problems when the libraries need
upgrade and we overwrite them (bootstrap will break). Or ensure
proper versioning here (which is nowhere done up=to-now in cm3).

Or (in case of build without ship) just specify the locations in the
workspace? Then we'd need to re-link cm3cg in case of later build and
ship.

What do you think?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194