Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] merged gcc and texlive

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] merged gcc and texlive
  • Date: Wed, 26 Aug 2009 17:58:16 +0200

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?

>
> Is it clear when the circular dependency causes problem and when not?
>
> Charles

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page