Hi, first of all, I know stage1 and stage2 are unsupported. But the bug described here, renders stage1 completely useless for everybody. as said in the summary. I cannot install from stage1 because system packages are depending on lzma-uitls which need c++ to compile but c++ isn't provided by gcc from stage1 archive. Reproducible: Always Steps to Reproduce:
there's no point in installing a neutered gcc into stage1
Could you provide the actual errors, preferably an emerge --tree output. We *shouldn't* need a c++ compiler in stages 1 and 2, but we should definitely be getting it before it's needed in stage3. If that means we have to re-enable c++ in stages 1 and 2, we can do that, but I'd prefer try to avoid it as much as possible. Also, you're working from the 2007.0 stages, I assume? We have the newer coreutils in the snapshot for 2008.0 (final, it didn't make it in time for Beta 2). As for the point of it, well, it's a carry-over from the old days of "stager" and probably doesn't need to be done, anymore, as we've changed how the stages are built. As I said, I'm fine with it being changed, so long as there's a good enough reason to do so.
until lzma-utils is rewritten in C (upstream is working on it), any package that is built in stage1/stage2 and uses an lzma tarball looks like it'll fail no idea what those packages are though
(In reply to comment #2) > Could you provide the actual errors, preferably an emerge --tree output. We > *shouldn't* need a c++ compiler in stages 1 and 2, but we should definitely be > getting it before it's needed in stage3. If that means we have to re-enable > c++ in stages 1 and 2, we can do that, but I'd prefer try to avoid it as much > as possible. Sorry, can't do as I already proceeded with installation (now from stage2). > Also, you're working from the 2007.0 stages, I assume? We have the newer > coreutils in the snapshot for 2008.0 (final, it didn't make it in time for Beta > 2). I used stage1-amd64-2008.0_beta1.tar.bz2
Mike, the only thing that needs it is coreutils in stage1, which is built using a C++-enabled GCC. Now, building our stages for the release, we've had no problems with this, so I'm really not sure what is going on for Lars.
(In reply to comment #5) > so I'm really not sure what is going on for Lars. Okay, I try to explain it a bit more. Currently when someone tries to install Gentoo from stage1, this won't work. The /usr/portage/scripts/bootstrap.sh will start compilation/installation as regular but when it comes to coreutils, lzma-utils are needed to unpack the coreutils sourcecode. And here stage1 fails to compile/install lzma-utils as the gcc shipped with stage1 doesn't have a c++ compiler but lzma-utils are in need of a c++ compiler to get compiled and installed. So now tell me the use a stage1 has when noone can use it to even install a base-system. I hope you understand the problem now...
I understand the build process just fine, thank you. As I stated before, we are not experiencing this, at all, with the 2008.0 builds. Also, you're not building stage1, you're using stage1. To build a stage1 requires a completely different process, normally carried out by catalyst. We don't pull coreutils into stage2, at all, which is the bootstrap phase. However, coreutils *is* in stage1. Now, I'm going to expect that this is likely caused by some USE flag that you've enabled/disabled. I can guarantee you that it works with the defaults set by Release Engineering, which is all that we support when it comes to stage1 and stage2. Remember, we don't care if those stages are usable for you. We don't support them. If you use them, you get to pick up the pieces yourself, especially when you're reporting a bug that I've tried to explain that we're unable to reproduce, across several architectures, and even across several userlands (default, hardened, uclibc), during the entire course of our more than 4 months of building stages. Let me clarify again that coreutils, the only package in system which requires lzma-utils, is present in the stage1 tarball, which is built from a stage3 seed with a full GCC. It is not installed, at all, during the bootstrap phase, and is only pulled in again for the "system" target when compiling stage3. This process works fine for the default settings employed by Release Engineering. All other uses of stages prior to stage3 are unsupported and Release Engineering doesn't approve nor wish for the removal of USE=build in the toolchain. As such, my recommendation is to WONTFIX this, or at least LATER, since I have no intentions on making this modification to the 2008.0 build this late in the game, anyway. Thanks
Perhaps its just me beeing a newb, but I read somewhere the other day that the new linux-headers 2.6.25 (masked with ~arch) are compressed in a lzma archive and therefore there is the need for lzma during bootstrap phase. My half a cent :)
Unless you can verify such claims, please don't clutter this bug with unverified rumors. As I said, much of the stuff that you guys are attributing to bootstrap issues aren't valid since they're really built at a much earlier stage, where a full GCC is available. Even if this is true, there's a different solution that I would prefer to use that requires a newer portage (current stable is fine) than was available last release.
Well, that sounds fair - check your own data ;) Luckily, that's something I actually managed to verify - if you check linux-headers-2.6.25-r1.ebuild there is a tar.lzma archive in SRC_URI and DEPEND="app-arch/lzma-utils" statement. It's possible to bootstrap if you mask te package - it will get you a 2.6.24 headers. The way it looks to me this ain't no bootstrap problem as such. So you're right, if you don't use ~arch keywords, the bootstrap phase will not fail. It's just an inconvenience one must circumvent in case more of a bleeding edge setup is desired. Cheers!
Created attachment 152737 [details, diff] toolchain-eclass-no-USE-build.patch i actually dont really see the point of USE=build anymore. if you dont want to do C++ in stage1/stage2 (which seems kind of useless nowadays anyways), then you can USE=nocxx. same goes for all the other USE flags. once 2008.0 is out, i'll commit this. note that this doesnt get rid of every USE=build occurrence, just the obvious ones. ive left in the edge cases as those will need further review by themselves.
(In reply to comment #10) > The way it looks to me this ain't no bootstrap problem as such. So you're > right, if you don't use ~arch keywords, the bootstrap phase will not fail. It's > just an inconvenience one must circumvent in case more of a bleeding edge setup > is desired. Cheers! I'm struggling with this issue at this moment, but while using crossdev. I've installed (stage3, hardened) a fresh system (2008 beta 2), but ran into this problem when building a cross-toolchain. And yes, just to confirm your findings, the problem is related to the ~x86 (possibly even other archs?) keyword. My 10b cents? I would switch back to bzipping distfiles for the time being.
not going to happen. the "lzma-utils needs C++" has been addressed in a different bug by providing a C-only decompressor-only build when USE=nocxx. as for hitting this when doing a cross-compilation on a fully setup system ... that's unrelated to this bug. go file a new one please.
*** Bug 265442 has been marked as a duplicate of this bug. ***
The great problem is the bootstrap.sh ignores nocxx flag if you specify it. So, I see two solution: don't filter out this flag, or specify explicitelly this flag at lzma-utils, because this package brokes the complete bootstrap process, and this isn't what we want. It can be related a different bug (this is a bug with bootstrap.sh) but my opened bug is marked as duplicate with this bug. Can anyone point me to a solution, or a really related bug? (In reply to comment #13) > not going to happen. the "lzma-utils needs C++" has been addressed in a > different bug by providing a C-only decompressor-only build when USE=nocxx. > > as for hitting this when doing a cross-compilation on a fully setup system ... > that's unrelated to this bug. go file a new one please. >
*** Bug 267200 has been marked as a duplicate of this bug. ***
