Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Jaka Kranjc (smgl AT lynxlynx.info) wrote [09.08.26 12:04]:
> On Wednesday 26 of August 2009 17:58:16 Arwed von Merkatz wrote:
> > On Wed, Aug 26, 2009 at 01:09:25PM +0800, Peng Chang (Charles) wrote:
> > > On Tue, Aug 25, 2009 at 05:21:51PM +0200, Arwed von Merkatz wrote:
> > > > I agree that this update should not need manual intervention,
> > > > especially for stuff as low in the dependency
> > > > tree/chain/graph/labyrinth as gcc. If gmp c++ support is the offender,
> > > > a possible solution is to include gmp inside the first gcc build and
> > > > then replace it later.
> > > > I'd rather have a few duplicates installed by spells than needing such
> > > > a manual process to get a working compiler.
> > >
> > > I made some experiment today. If we include gmp and mpfr inside gcc
> > > source tree, all gmp and mpfr objects are statically compiled into gcc
> > > binaries and libraries, and none of the gmp or mpfr libraries will get
> > > installed, which means this approach does not conflict with current gmp
> > > or mpfr spells.
> > >
> > > 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?
> Potential conflict with the system one if they are installed. On my machine 
> alone there are 6 other spells that need gmp.
> 
> Peng: about the bug comparison: that bug only happens when also the 
> archspec 
> changes, while the transition would hit everyone.

There's also the issue of choice. If gcc can either be built with
statically or dynamically with gmp, then a user can have the choice of a
dynamic gmp for a desktop system and a static gmp for an embedded
system.

Perhaps we could develop a way for sorcery to automatically cast a spell
with forced subdepends, and then recast with optional features
afterwards? As in, if g++ forces gmp, and g++ is being cast, then cast
gmp without g++ support first, and then after gmp and g++ are cast
automatically recast gmp with the optional support for g++ (if the user
chose to have it). I may not be making total sense with this right now,
as I'm rather sleepy today.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpvb9Qufuha3.pgp
Description: PGP signature