During stage1 of bootstrap we don't have CXX compiler Example: If you're using ~arch during bootstrap, binutils are packed with lzma - which will pull lzma-utils. It won't build without nocxx use flag and bootstrap process will fail. Similar for gmp. The problem can be solved by adding nocxx to STAGE1_USE. This step should be safe, as we don't have c++ compiler in stage1. I realise stage1 is no longer officially supported, but as long as there are stage1 stages and script/bootstrap.sh exists, this should work. Reproducible: Always
vapier: +1 from me to add nocxx back for lzma to be happy.
no one removed USE=nocxx from lzma-utils
vapier: I said add it back meaning to the bootstraps, not the package.
i really dont know what you're referring to ... if lzma-utils builds with USE=nocxx, then there's nothing for base-system to look at ...
ok I don't know who changed my Summary. Originally it was about not having nocxx USE flag in bootstrap. When you run bootstrap.sh new binutils (~arch) is packed with lzma which fails to compile without nocxx flag (as we don't have cxx compiler yet). The bug is about modifying bootstrap.sh and adding nocxx USE flag _until_ we have cpp compiler (we can't have this flag during gcc compilation as it won't build cpp support at all). lzma-utils was just an example package which would require nocxx USE flag during bootstrap. I hope it's a bit more clear now. Sorry if I didn't word it properly 1st time. R
assuming the build of lzma-utils actually works which makes this a release issue i dont know why we dont just have a C++ compiler in stage1 ... that'd make things simpler
The reasons for not having a C++ compiler in the stage1 are probably "legacy" and completely irrelevant these days. It may have just been to reduce the size of the stage1 tarball for back when people still used them as a common install method. What USE flag is currently used to trigger this behavior? Looking at toolchain.eclass, the build/bootstrap USE flags are only used to control whether to run gcc-config and apply some SSP patch. Is it even in the stage1 itself that we have a gcc without C++, or does that happen when gcc is rebuilt as part of the bootstrap (stage1 -> stage2) process?
yes, that's because i've been silently culling stupid USE=bootstrap/build from ebuilds in the case of the toolchain.eclass though, there was a dedicated bug open on the topic and wolf said he didnt see any problems with the change, and in general he agreed with it (that is, removing bootstrap/build from toolchain.eclass since it for the most part mirrored USE=nocxx)
So, then will this even be an issue with future stage builds? Since nocxx isn't set by default for a stage1 build or during a bootstrap run, we should have a gcc with C++, correct?
no idea ... i havent done a catalyst build in a while i guess if you make a stage1 today with the latest tools and it has C++ support, then there's nothing to do here ...
What's the quickest/easiest way to check with a freshly extracted stage1?
Okay, it looks like both stage1 and stage2 (both built on 20081128) have c++ support. Sounds like this is moot.
yeah, if `g++` works in stage1 -> nothing to do
(In reply to comment #12) > Okay, it looks like both stage1 and stage2 (both built on 20081128) have c++ > support. Sounds like this is moot. > That would make that bug completely solved. Where can I get more recent stage1/stage2 images? The one listed at mirror://gentoo/releases/amd64/2008.0/installcd/ are dated 18-Aug-2008
for releases, we do not "FIX" as in "put out new images". release images are expected to *work*, and "simple" changes can easily blow that. so in the context of the release team, "FIX" means it's in the tools and the next release will see the change. if you want the fix, you need to build your own images.
(In reply to comment #15) > for releases, we do not "FIX" as in "put out new images". release images are > expected to *work*, and "simple" changes can easily blow that. > > so in the context of the release team, "FIX" means it's in the tools and the > next release will see the change. if you want the fix, you need to build your > own images. > Great got it. Thanks guys for your time looking into that.
