On Fri, 2007-11-16 at 19:34 +0100, Jan Stępień wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Gianelloni wrote: > > On Fri, 2007-11-16 at 08:51 +0100, Jan Stępień wrote: > >> I've been trying to create a live CD using catalyst building my own > >> stage(1-3). I've downloaded stage3-i686-2007.0.tar.bz2 (MD5 sum > >> 55f18797e55a19f1f7d43d649f416504) and ran: > > > > Use a generic stage. Do not use an i686 stage3 as a seed, use an x86 > > one. Your stage1 subarch should be "x86" not "i686"... I would also > > suggest not using the C(XX)FLAGS you've chosen. Add a -march=i686. > > You're already building i686-only binaries via subarch i686, it makes no > > sense to under-optimize the binaries, too. ;] > > > > Let us know if those things didn't fix it. > > Thanks a lot for your response. Meanwhile, I've managed to build all > three stages starting with the mentioned stage3-i686-2007.0. The method > I've came up with is following: > > # catalyst -f stage1.spec > # rm -r <package dir> > # catalyst -f stage2.spec && catalyst -f stage3.spec > > Actually I'm not sure whether removal of gcc package only wouldn't solve > the problem, but I have to admit I hadn't got neither time nor patience > to give it a try.
I ran into a similar problem as you did. The problem is that the value for pkgcache_path is the same for stages 1, 2, and 3 in your spec files. As a result, the sys-devel/gcc package built in stage1 was reused in stages 2 and 3. I resolved this by specifying unique pkgcache_path values for all catalyst targets (eg /var/tmp/catalyst/packages/<target>/<rel_type>). Regards, sf -- [EMAIL PROTECTED] mailing list
