Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 257901 - stage1 bootstrap.sh tries emerging lzma-utils with USE="-nocxx"
Summary: stage1 bootstrap.sh tries emerging lzma-utils with USE="-nocxx"
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: Stages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-06 14:41 UTC by Lutz Lehmann
Modified: 2009-12-27 17:08 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lutz Lehmann 2009-02-06 14:41:55 UTC
As title says :)

In the third part of the bootstrap, lzma-utils is being pulled in as a dependency with USE="-nocxx". Since gcc in stage1 is rather crippled, the CXX-support is missing, thus causing the build of lzma-utils to fail.

Trying to bootstrap with USE="nocxx" won't work since the script sets it's own USE-flags.

Reproducible: Always

Steps to Reproduce:
Comment 1 Andrew Gaffney (RETIRED) gentoo-dev 2009-02-06 15:14:01 UTC
We haven't hit this problem in any of our automated stage builds. Regardless, the stage1/2 installs aren't supported. If it breaks, you get to pick up the pieces.
Comment 2 Lutz Lehmann 2009-02-06 15:45:51 UTC
(In reply to comment #1)
> We haven't hit this problem in any of our automated stage builds. Regardless,
> the stage1/2 installs aren't supported. If it breaks, you get to pick up the
> pieces.

1) Thanks ever so much. I managed to get the system up and running anyways. Care to know how?

2) Looking at the date when stage1 was last built, it's no wonder you've never seen this happen. The c++-dependant lzma-utils became a core dep (for portage itself, AFAIR) not too long ago. The problem didn't show up because the package didn't get pulled in back then.

3) Support for stage1 and stage2 builds has been dropped years ago. Why in the world do they get rebuilt every once so often if they're not to be used?

4) If *I* manage to get the code fixed, is it even worth submitting the patch?
Comment 3 Lutz Lehmann 2009-02-06 15:50:42 UTC
By the way, have a look at this:

http://bugs.gentoo.org/show_bug.cgi?id=207200#c9
Comment 4 Andrew Gaffney (RETIRED) gentoo-dev 2009-02-06 16:03:31 UTC
The last set of stages were built just yesterday (for amd64) and the day before (for x86).

The only reason stage1 and stage2 are still built, is because they are a by-product of the procedure to generate a stage3.
Comment 5 Lutz Lehmann 2009-02-07 00:59:21 UTC
(In reply to comment #4)
> The last set of stages were built just yesterday (for amd64) and the day before
> (for x86).

Didn't know that, the stages on the mirrors I checked are still dated 06-30-08.

> The only reason stage1 and stage2 are still built, is because they are a
> by-product of the procedure to generate a stage3.

Any hint on how you do that without bootstrapping?
Comment 6 Andrew Gaffney (RETIRED) gentoo-dev 2009-02-07 15:47:26 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > The last set of stages were built just yesterday (for amd64) and the day before
> > (for x86).
> 
> Didn't know that, the stages on the mirrors I checked are still dated 06-30-08.

Look under /experimental/${arch}/autobuilds/ on your favorite mirror.

> > The only reason stage1 and stage2 are still built, is because they are a
> > by-product of the procedure to generate a stage3.
> 
> Any hint on how you do that without bootstrapping?

We don't. The stage build process uses the bootstrap.sh script just like you're trying to do.