Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:37, Sven Köhler wrote: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. ive chatted with wolf and the real fix here is to change the 'emerge clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way when you emerge a new SLOT-ed version of gcc, the old stripped down version in stage1 is automatically pruned I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? ??? I just wanted to say Thank you for both fixes. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:50, Sven Köhler wrote: I also noticed the --oneshot fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? ??? I just wanted to say Thank you for both fixes. sorry i forgot the /joke -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 03:40, Sven Köhler wrote: Seems like a bit ranting to me. Why do you use unsupported installation method if you want it simple? I don't know about Sven, but the reasons I prefer the unsupported installation method is all outlined here: I have no clue, what bootstrap.sh is for anymore. For me, Installing gentoo was always like this: Ok, let me remind all. Stage 1 is a minimal system that is mainly built statically with the sole purpose of being suitable to build a working system from. It contains a cripled compiler as one of the first things it does is make a proper one. After that the original compiler should be gone. While some recompiling is needed because of circular dependencies between libc and gcc, this should be no issue. After the bootstrap has been run, one should have a proper minimal building environment that should be able to build all packages (except for some assumptions on available tools). This minimal environment is called stage 2. Stage 2 should not contain any trace of the bootstrap compiler. If the bootstrap compiler was a 3.3.x version and the final one a 3.4.x version, there should be no 3.3.x version remaining. Be aware though that if the profile does not offer a 3.4 compiler the final will be a 3.3 compiler. If desired the profile should be changed before running bootstrap.sh Because many ebuilds make assumptions about the environment, and because a stage 2 will not boot by itself, a number of utilities deemed essential must be installed. Those are part of system. The main ingredient being baselayout with it's dependencies. Baselayout is what takes care of booting your system into a working order. Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4. Then he's telling me, that the problem, that Im trying to point out, is going to vanish with the release of the 2006.0 tarballs. Well, yes, until the next gcc-slot becomes stable. So the problem is not fixed, just moved to the future again. If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is used as the main, that is a bug in the bootstrap script. As such it should be fixed. Stage 3 installs just dump a fully functional system, so as such one should then just take the steps from the handbook that make it bootable. After that the gcc-upgrade guide can be followed, except that world update is not really needed, and that world normally also includes system such that emerge -e system emerge -e world is extraneous. Pretty much work for a beginnner! And there's pretty much of experience needed. It's easier than going from stage 1. It is possible to skip all the unneeded compiling, but it's easy to fuck up, and very hard to explain. That's why stage 1 is discouraged. Actually, the moment when there's an upgrade to glibc and gcc, than there's no advantage in taking a stage3 - the whole upgrading the stage3-thing will take as long as using a stage1. Why? because i have to upgrade glibc and gcc - and that is basically what bootstrap.sh does too. Not really, bootstrap.sh does things in a specific order to take care of cyclic dependencies that fail because stage1 is a minimal ( say crippled ) environment. But indeed you're better off with a stage3 that is based on a current glibc and gcc version. Minor version numbers don't matter much though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpvVHx9sgVgK.pgp Description: PGP signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thu, 2006-01-26 at 03:40 +0100, Sven Köhler wrote: Pretty much work for a beginnner! ...and? You're using a source-based distribution. It is not designed for the beginner insomuch as you have to perform maintenance tasks that would otherwise be unnecessary in a binary-only distribution. And there's pretty much of experience needed. Yes, there is. There's also the ability to follow the directions given by ebuilds when they're merged. Actually, the moment when there's an upgrade to glibc and gcc, than there's no advantage in taking a stage3 - the whole upgrading the stage3-thing will take as long as using a stage1. Not quite. Why? because i have to upgrade glibc and gcc - and that is basically what bootstrap.sh does too. ...and headers, and portage, and baselayout, and binutils, and texinfo, and zlib, and ncurses... Something else that *everybody* seems to be missing is that the *first* method in the GCC upgrading guide, which is the one that would apply from a fresh-installed system, seems to be completely overlooked by all the naysayers. Funny how if someone actually read the entire document, they'd see just how much of their own time they're wasting. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thu, 2006-01-26 at 14:54 +0100, Sven Köhler wrote: I think that i clearly explained several times, that bootstrap.sh installs gcc 3.4 _without_ removing the crippled gcc 3.3 that came with stage1. You are absolutely correct. We will need to investigate the best solution for this. The reason the old compiler is not removed currently is because of them being in a different SLOT, and therefore protected from being unmerged by clean actions. If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is used as the main, that is a bug in the bootstrap script. As such it should be fixed. So i see that you seem to agree with me! The crippled gcc contained in the stage1 has to be removed by bootstrap.sh - and this is not done automatically by the steps that bootstrap.sh performs. I agree also. I would also like to state that until this email, that I had no idea that this was what you were describing. I'll get right on a possible solution. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 00:14, Homer Parker spammed: On Wed, 2006-01-25 at 21:06 -0600, Mikey wrote: Solutions? And how many have you tested and submitted patches for? Instead of just complaining, be proactive and help with the problem you perceive is there. If it's a viable solution, it'll probably be at least discussed. Then there's a matter of the manpower to maintain said solution. One of Yes, I have submitted patches, as well as reported the bugs. Most often the response is that stage1's are going away, you don't know what you are talking about, you are an idiot, yadda yadda yadda. Step one of problem solving is admitting that there is a problem in the first place. I believe there is. pgpmqHnWfnE2y.pgp Description: PGP signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 08:54, Sven Köhler wrote: Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 08:12, Chris Gianelloni spammed: Something else that *everybody* seems to be missing is that the *first* method in the GCC upgrading guide, which is the one that would apply from a fresh-installed system, seems to be completely overlooked by all the naysayers. Funny how if someone actually read the entire document, they'd see just how much of their own time they're wasting. Have you even read the bug reports and forum threads on upgrading gcc via that method? pgp2xNFrCer7W.pgp Description: PGP signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 So let me summarize that again: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 13:23, Sven Köhler wrote: Mike Frysinger is talking about choice and ignores me if i tell him, that the emerge -e system uses the crippled gcc 3.3 for the first 10 packages until emerge -e system finally rebuilds gcc 3.3 (only due to some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc 3.3). i didnt ignore you, i told you that's the intended behavior neither you nor portage changed the compile thus it remained at 3.3 So let me summarize that again: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. currently, yes, that is the intended behavior -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Thursday 26 January 2006 13:23, Sven Köhler wrote: You say, that it's the intended behaviour, that bootstrap.sh keeps the crippled gcc 3.3 intact and as the default compiler. ok, i looked into this some more and ran some tests ... long and short of it is that the behavior i discussed before applies only in a stage3 and beyond ... the gcc-config logic is specifically tweaked during bootstrap and build (i.e. stage1 and stage2), thus everything i said wrt to automatic switching of gcc has no bearing on this discussion ive chatted with wolf and the real fix here is to change the 'emerge clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way when you emerge a new SLOT-ed version of gcc, the old stripped down version in stage1 is automatically pruned -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Wed, 2006-01-25 at 22:09 +0100, Sven Köhler wrote:
I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \${gcc package that we just compiled})
so that a clean system is built with gcc 3.4 only!
Nope. We don't want to remove that choice from the user. We are
working now towards the 2006.0 release, which means GCC 3.3 will not be
present in the stage1 tarball. Basically, wait for 2006.0, or follow
the standard steps to switch compilers yourself. It's not like we're
forcing you to keep both compilers. ;]
As i wrote in my other post:
there is no choice! boostrap.sh does what it does:
- installs gcc 3.4
Only because it is unmasked. You could always mask 3.4 to keep it from
installing. Yes, this is your choice.
- leaves the gcc 3.3 from the stage1 tarball unchanged
You could also remove 3.3 after doing your bootstrap. Remember that
part in the Handbook that says you really shouldn't be playing around
with bootstrap if you don't know what you're doing and willing to do
work on your own system? Here's a prime example.
So actually the first packages compiled by emerge -e system are
compiled with the gcc 3.3 which came with the stage1 tarball.
Again, this is completely because of you not making any changes on your
system.
And that emerge -e system updates gcc 3.3 - well, that is only a
side-effect of other things!
Which you won't have to deal with for long, 2006.0 is being worked on as
we speak. The basic jist of this is that what you are seeing is pretty
much expected behavior for bootstrapping using a stage with an older
GCC.
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
Sven Köhler wrote: That's not a problem for me. So excuse me that i wanted gentoo-installation to be more simple. Seems like a bit ranting to me. Why do you use unsupported installation method if you want it simple? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Wed, 2006-01-25 at 23:27 +0100, Sven Köhler wrote: IMHO, i would expect that /usr/portage/scripts/bootstrap.sh; emerge -e system results in a system, that has a certain integrity with a minimum of manual steps. (gentoo install being as easy as possible) That has never been the case. The entire *point* of bootstrap is so that you can *customize* the system. If you're doing /usr/portage/scripts/bootstrap.sh; emerge -e system with no customization, you're wasting your time. You get identical results from a stage3 tarball + edit make.conf + emerge -e system + emerge -v depclean, and it is a faster method, too. At the moment, /usr/portage/scripts/bootstrap.sh; emerge -e system produces a system, that is IMHO unexpected for most users. This is exactly why we do not recommend a stage1 installation to anyone that is unwilling to do work to modify the installation themselves. Using stage1 assumes that you know what you are doing. That's not a problem for me. So excuse me that i wanted gentoo-installation to be more simple. It is quite simple. The documentation is quite extensive on installing from a stage3 tarball. How much simpler can you get? ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Wednesday 25 January 2006 21:40, Sven Köhler wrote: I expected the result of these steps to be a clean system. What do i mean with a clean system? Actually i thought, that i mean the result of a emerge -e system - but i know now, that this is not what i mean. For example emerge -e system sometimes choses to install gcc-3.3 instead of the default libstdc++-v3. what you want to happen just isnt feasible at this point in time (if it ever will be) portage does not automatically change the version of gcc across major versions ... this is done on purpose as there is no way of knowing whether the user wants the new version of gcc to be the default system one or whether they are just installing a new one for fun you want bootstrap.sh to basically automatically run `emerge gcc emerge prune gcc` ... this is not doable as packages may be tied to the older version of gcc ... and in fact, python itself currently links against libstdc++, so if bootstrap followed the automated steps listed above, you'd end up with a broken python (and thus a broken emerge) thus, in order to get a clean system you're so keen on, you need to run bootstrap.sh to get a 3.4 compiler, switch your default compiler to 3.4, rebuild anything that is linked against 3.3 with 3.4, prune 3.3 from your system, and then continue on with the `emerge -e system` -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Wed, 2006-01-25 at 21:06 -0600, Mikey wrote: Solutions? And how many have you tested and submitted patches for? Instead of just complaining, be proactive and help with the problem you perceive is there. If it's a viable solution, it'll probably be at least discussed. Then there's a matter of the manpower to maintain said solution. One of the reasons of going to stage3 as the only supported method is the ingenious ways users break their systems from stage1, and the overhead of dealing with bogus bugs. -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Linux Developer Relations [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
