Public SourceMage Discussion List

["Peng Chang (Charles)" <chp516 AT gmail.com>]

On Wed, Aug 26, 2009 at 05:58:16PM +0200, Arwed von Merkatz wrote:
> > chp@pc:~$ ldd /usr/libexec/gcc/i686-pc-linux-gnu/4.3.3/cc1
> >         linux-gate.so.1 =>  (0xb7f69000)
> >         libmpfr.so.1 => /usr/lib/libmpfr.so.1 (0xb7edf000)
> >         libgmp.so.3 => /lib/libgmp.so.3 (0xb7e8c000)
> >         libc.so.6 => /lib/libc.so.6 (0xb7d42000)
> >         /lib/ld-linux.so.2 (0xb7f4d000)
> > chp@pc:~$ ldd workspace/test/libexec/gcc/i686-pc-linux-gnu/4.3.3/cc1
> >         linux-gate.so.1 =>  (0xb80cc000)
> >         libc.so.6 => /lib/libc.so.6 (0xb7f51000)
> >         /lib/ld-linux.so.2 (0xb80b0000)
> > chp@pc:~$ ls workspace/test/lib | grep gmp
> > chp@pc:~$
> > 
> > The drawback of this approach is that these gcc binaries are not
> > dynamically linked against gmp/mpfr libraries. When gmp updates, these
> > libraries will not benefit from the update. It is best if the gcc spell
> > can automatically choose to compile with system gmp/mpfr when possible,
> > with compiling with embedded gmp/mpfr as an alternative.
> 
> I'd rather the gcc spell always worked the same. Is there any good
> reason for not including gmp/mpfr in the gcc spell statically, besides
> having to recompile gcc when they are updated?

One of the benefit of dynamic linking is that we don't have to compile
the applications each time the library updates. gcc is a huge and time
consuming spell while gmp/mpfr are lightweight. Updating gmp or mpfr
triggers recompiling gcc is not time saving. However, if we decide to
recompile gcc when gmp or mpfr are updated, it's OK to do so. And
there's a good reason to do so. For gcc making use of some updated
libraries, it may be time to do a sorcery rebuild, including recompiling
gcc of course.

Charles