Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.4
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Thu Jul 14, 2005 10:41 am    Post subject: Reply with quote

I think he means that with the 2.6.12 kernel series and the newest stable splashutils, warnings pop up during their emerge that say to re-emerge splashutils after upgrading to that new kernel, which the newest splashutils requires. Also, the splash themes are no longer included in the splashutils package; they must be separately emerged with, for example, emerge media-gfx/splash-themes-gentoo. And finally, the new splash needs to be rebuilt by another geninitramfs command.

Oh, and there are now several *required* boot options that must be appended to the appropriate grub entries, including new formats for the previous options present in this Guide. I've been following the splash/kernel developments, and here are the related threads:

gentoo-sources-2.6.12 borks fbsplash
Kernel upgrade - bootsplash broken
boot error, vesafb/splashutils related
fbsplash problems with 2.6.12-gentoo-r4
Back to top
View user's profile Send private message
zendal
n00b
n00b


Joined: 30 Nov 2002
Posts: 23
Location: Amberg, Germany

PostPosted: Thu Jul 14, 2005 12:03 pm    Post subject: FBSplash Reply with quote

I went back
2.6.11 kernel
0.94 grub
and emerged the themes

There is also error in the package.keywords he typed

Quote:
~sys-devel/gcc-3.4.4 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86


Should be
Code:
sys-devel/gcc ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86


For the package.mask if you want 2.6.11 and working grub
Code:
>sys-kernel/gentoo-sources-2.6.12
>sys-boot/grub-0.96


For the emergence them to be there
Code:
emerge splash-themes-gentoo

If you want more there is another theme file
Code:
emerge splash-themes-livecd
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Thu Jul 14, 2005 4:32 pm    Post subject: Re: FBSplash Reply with quote

zendal wrote:
There is also error in the package.keywords he typed

Quote:
~sys-devel/gcc-3.4.4 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86


Should be
Code:
sys-devel/gcc ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86



actually, the package keywords file is accurate as it exists in the Guide:
Code:
~sys-devel/gcc-3.4.4 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86


this version of the Guide is specifically desgned to install GCC 3.4.4 and no other version of the GCC compiler. the atom masking syntax used in the Guide's package.keywords file assures that only GCC 3.4.4 will be installed. although the less specific syntax that you have recommended works right now (because GCC 3.4.4 is the latest unmasked testing branch ebuild in the portage tree) it undermines the specificity of the Guide's approach by allowing any more recent testing branch versions of GCC that are not masked to be installed in its place once they enter the portage tree.

suffice it to say that i've chosen to use the syntax that is used in the Guide because it will remain correct forever. i chose to replace the syntax that i had previously used (the exact syntax that you had recommended) because it won't remain correct forever -- although it is right for now, eventually it will become wrong.



regarding the FB splash and kernel stuff: i haven't taken the time to investigate the idiosyncracies of the 2.6.12 kernels as related to framebuffer splash and the bugs that have been inherent in its implementation. i have had an open bug report on bugzilla about FB screenblanking errors that began with 2.6.9 kernels and have been persistent until now. supposedly, Spock's newest additions to the 2.6.12 kernels have fixed the nagging problem that has been persistent from 2.6.9 through 2.6.11, and it appears that they require an upgrade of both gensplash and grub in addition to a kernel upgrade to fix the bug. unfortunately, because 2.6.12 has been marked in the testing branch for most of its life, i haven't bothered to tinker with it. i just don't have time for testing branch kernels anymore. @nightmorph, thanks for those links that show all of the trouble i've been missing. :D

thank you @zendal for posting the updates to the Guide relating to the new kernels, FB utils, and grub, and also for the contribution about masking for people who want to stay with the older kernels.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Thu Jul 14, 2005 9:27 pm    Post subject: Newbie questions about some steps in the guide Reply with quote

Hello,

I have some questions about some steps in the guide that I don't understand.

(1) Why do we need to install libstdc++-v3? I know that when compiling gcc from sources, at least from version 3.4.0, the c++ library is automatically compiled at the same time. I've compiled lots of gcc-3.4.0 to gcc-4.0.0, with support for C,C++ and other languages, without ever undertaking any special actions with regard to libstdc++, except asking C++ support at configure. Is it perhaps because "emerge" doesn't work as a normal "configure && make (bootstrap) && make install" cicle?

(1.5) I have put parenthesys in "make bootstrap" because I want to know whether or not "emerge gcc" performs a real gcc bootstrap (three stages) or a simple make. How does it work?

(2) In section 7.2.4 (Rebuilding the System Toolkit) there's the following instruction:

# emerge -e system && emerge -e system

Why is it needed to repeat twice the same operation, seen that before that point we already have a new toolchain built with gcc-3.4.4? What am I missing?
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Thu Jul 14, 2005 10:17 pm    Post subject: Reply with quote

1) IIRC, libstdc++ provides backward compatibility for the regular 3.3.x gcc series.

1.5) Emerging gcc is just that--compilation and installation of a package, not any special bootstrap per se.

2) This has been explained many times in the Stage 1/3 guides, the Jackass! Guide, and heilvc's correct toolchain thread. Please do look through those for detailed answers, but in short, recompiling the toolchain is necessary. Until that step, the only thing you have done is emerged a new toolchain and switched to that compiler. However, you have not yet begun using it; every package has been build with the wrong (read: OLD) gcc. Thus, now you have to recompile your packages in order to get immediate benefits of the new toolchain. If you do not recompile your system, then not only will it be somewhat unstable, but only future packages you emerge--like Gnome or AbiWord--will be built with the 3.4.4 toolchain. The rest of your system will still only be compiled from a 3.3.x toolchain, which is obviously undesirable.

Again, please search for the threads that I mentioned if you need further clarification; these questions come up over and over in those guides.
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Fri Jul 15, 2005 8:21 pm    Post subject: Reply with quote

nightmorph wrote:
1) IIRC, libstdc++ provides backward compatibility for the regular 3.3.x gcc series.


Why backward compatibility is needed? Don't we then re-compile all sources with 3.4.4? Don't we prune the gcc-3.3.5 compiler at section 7.2.5 (Prune the GCC Compiler) and then use only gcc-3.4.4 to "emerge -e system"?

Anyway I don't see any need to put re-compilation of an old libstdc++, even for compatibility (?!) reasons, in toolchain re-building, seen that it has got nothing to do with the workings of the new toolchain, it has nothing to do with newly compiled glibc and binutils too, so I think is plain wrong. (I would add that even name the toolchain as a "toolkit" is misbehaviour and potentially misconducting).

Quote:
1.5) Emerging gcc is just that--compilation and installation of a package, not any special bootstrap per se.


No, I'm sorry it's not true. I have now noticed that gcc is completely bootstapped, no simple "make". The command I see with "ps aux" is "make profiledbootstrap" (three stages + profile collection) that is a very different thing than "make".

Quote:
2) This has been explained many times in the Stage 1/3 guides, the Jackass! Guide, and heilvc's correct toolchain thread. Please do look through those for detailed answers, but in short, recompiling the toolchain is necessary. Until that step, the only thing you have done is emerged a new toolchain and switched to that compiler. However, you have not yet begun using it; every package has been build with the wrong (read: OLD) gcc. Thus, now you have to recompile your packages in order to get immediate benefits of the new toolchain. If you do not recompile your system, then not only will it be somewhat unstable, but only future packages you emerge--like Gnome or AbiWord--will be built with the 3.4.4 toolchain. The rest of your system will still only be compiled from a 3.3.x toolchain, which is obviously undesirable.


I am not speaking about the toolchain re-compilation, at all. What makes you to think that? At that point, that is at the end of section 7.2.4, we have already been said to rebuild the toolchain. So I am not speaking about the need to rebuild the toolchain, that is correct!

I am objecting about the need to do "emerge -e system && emerge -e system", that is after toolchain re-building with the new gcc-3.4.4. This means that we compile gcc, glibc e binutils FOUR times in total. Twice is correct, four times is again plain wrong and wasting of precious time.

What's more important is that there is no need I can imagine to "emerge system" twice, one after another as showed by "emerge system && emerge system". Whay do you think is it not enough to issue "emerge system", I mean only once? Every source at this point would be compiled by the new toolchain, the one that has already been rebuilt, and I think there would no difference in executables if you issue either a simple "emerge system" or "emerge system && emerge system && emerge system && ...". Doing it twice or more is plain wrong.

I have further noticed that in the other guide, Stage 1/3 Installation for Gentoo 2005.0 and GCC 3.4.3, that in the same section (7.2.5) there aren't the same mistakes. Just one of them ("-e" option). Please take a look at that. There is only ONE "emerge -e system" after toolchain re-building.

So, why do you think there are these differences between the "Installation 1/3 with gcc-3.4.3" and "Installation 1/3 with gcc-3.4.4"?

Quote:
Again, please search for the threads that I mentioned if you need further clarification; these questions come up over and over in those guides.


I'm sorry, but I am not able to find answers about the above-mentioned issues in this guide as you say they have been trated. Don't know what is the "Jackass" and how this topic is related to this guide.

Anyway I would like to hear on the above-mentioned issues from the guide's author too, if He is available to argue about his choices and explain them.
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Fri Jul 15, 2005 8:56 pm    Post subject: Reply with quote

kueitao wrote:
I am not speaking about the toolchain re-compilation, at all. What makes you to think that? At that point, that is at the end of section 7.2.4, we have already been said to rebuild the toolchain. So I am not speaking about the need to rebuild the toolchain, that is correct!

No, you are still incorrect. Please read step 7.2 carefully. Nowhere does it say that the toolchain has been rebuilt in 7.2.4--and yes, this is the gcc 3.4.3 guide, but the two are procedurally identical except for the particular gcc version used, that's all. The heading for the entire section is "rebuilding the toolchain" which is what will happen--NOT that it has been done by step 7.2.4. Prior to that step, the only thing that has been done is the new toolchain has been emerged. It has not yet begun to be rebuilt. Now that it is unmasked, it is installed. And then you need to start recompiling your system--which has still built only with 3.3.x to this point--in order to take advantage of it. Ignore any section title text that says "rebuilding" up through 7.2.4 and just look at the content of each step. Nowhere is there any recompiling, only the emergence of masked ~x86 toolchain packages. You really need to examine the procedure more carefully and not jump to conclusions.

The point of each successive emerge -e system is to verify that all the code is produced from gcc 3.4 and its supporting components. But this is not possible with only a simple emerge gcc binutils gcc-config glibc. See, since the new tools themselves were compiled with 3.3.x, they can only optimize the existing system code up to a certain point when you do the first emerge -e system. At that point they've rebuilt themselves but still only suboptimally. It takes the next few emerge -e system/world commands in order to remove any hint of the original 3.3.x compilation. Please read this thread to hear the more technical explanation of why this is necessary.
Quote:
I'm sorry, but I am not able to find answers about the above-mentioned issues in this guide as you say they have been trated. Don't know what is the "Jackass" and how this topic is related to this guide.

See the link in my signature. Jackass! provides a canned version of this stage 1/3 install, but all the compiling has been done in advance. Same CFLAGS and NPTL advantages, but we took the trouble to compile everything ahead of time, so that your hardware is spared the abuse of recompiling. Really, though, if you don't think you have time to be recompiling or compiling at all, Gentoo might not be the best solution for your needs. Note that as Bob mentioned, anytime there is an update to one of the toolchain components, you will need to spend some time rebuilding your system, including a few emerge -e system commands, in order to reap the benefits of the new package.
Back to top
View user's profile Send private message
Dark_Cloud
n00b
n00b


Joined: 29 Jun 2003
Posts: 27

PostPosted: Sat Jul 16, 2005 2:03 am    Post subject: Reply with quote

Sorry, but i still disagree with you... in 7.2.4 Rebuilding the System Toolkit the toolkit was totally rebuilt and at the final of that we had a working gcc-3.4.4 and all the packages (of course) built with gcc-3.3.5. When we performe the emerge -e system we are compiling all the packages including the gcc with the existing gcc-3.4.4... so after that we have a system totally built with gcc-3.4.4... it isn't necessary to use emerge -e system again.

sorry about my poor english, trying to develop it :wink:

cheers:D
_________________
Powerred by Gentoo Linux 2005.0
2.6.12-ck4 i686 AMD Athlon(TM) XP 2600+
GCC 3.4.4, glibc 2.3.5 (NPTL)

E17 cuz it's CUTE and FAST! Just Get-E
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Sat Jul 16, 2005 11:23 am    Post subject: Reply with quote

I'm sorry about my poor English, as Dark_Cloud is. It seems I am not able to drive nightmorph to the point. Except for the issues related to the old libstdc++ and the "make (profiled)bootstrap", for which He didn't reply to my last post, I suppose...

Please read carefully the following from Dark _Cloud. I hope He is better than me in showing the issue:

Dark_Cloud wrote:
Sorry, but i still disagree with you... in 7.2.4 Rebuilding the System Toolkit the toolkit was totally rebuilt and at the final of that we had a working gcc-3.4.4 and all the packages (of course) built with gcc-3.3.5. When we performe the emerge -e system we are compiling all the packages including the gcc with the existing gcc-3.4.4... so after that we have a system totally built with gcc-3.4.4... it isn't necessary to use emerge -e system again.

sorry about my poor english, trying to develop it :wink:

cheers:D


I'll try even a better approach by pasting from the guides. Please remind that I'm interested only in installation with gcc-3.4.4 that is the one I argue it is wrong.

The first quote is from installation with gcc-3.4.3 and it is the one I consider good , except for the "-e" option:

Quote:

7.2.5 Rebuilding the System Toolkit

Now its time to rebuild the toolkit. We'll start off by recompiling glibc, binutils, gcc, and by updating portage. This will rebuild our GCC 3.4.3 compiling toolkit (which had previuosly been compiled with GCC 3.3.5) with the GCC 3.4.3 compiler, taking advantage of our new USE flags and CFLAGS compiler settings.

Code:

# emerge glibc binutils gcc portage

Upon completion of the rebuild of the compiling toolkit, we will recompile the entire system to assure that our entire toolkit has been compiled using GCC 3.4.3 and our hardware-specific settings.

The result will be a 3.4.3 tooklit and an entire system that is built with a 3.4.3 toolkit, that was built with a 3.4.3 toolkit.

Code:

# emerge -e system


The second quote is from installation with gcc-3.4.4 and it is the one I consider to be wrong :

Quote:

7.2.4 Rebuilding the System Toolkit

Now its time to rebuild the toolkit. We'll start off by recompiling glibc, binutils, gcc, and by updating portage. This will rebuild our GCC 3.4.4 compiling toolkit (which had previuosly been compiled with GCC 3.3.5) with the GCC 3.4.4 compiler, taking advantage of our new USE flags and CFLAGS compiler settings.

Code:

# emerge glibc binutils libstdc++-v3 gcc portage

Upon completion of the rebuild of the compiling toolkit, we will recompile the entire system to assure that our entire toolkit has been compiled using GCC 3.4.4 and our hardware-specific settings.

The result will be a 3.4.4 tooklit and an entire system that is built with a 3.4.4 toolkit, that was built with a 3.4.4 toolkit.

Code:

# emerge -e system && emerge -e system


Do you, nightmorph, see the differences between them? The two guides aren't identical despite what you assert... How can you explain it? Furthermore from the first guide you can see that there's no need for an old libstdc++ installation as I pointed out even before reading that document (installation with gcc-3.4.3), because I was only trying an installation with gcc-3.4.4.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Jul 16, 2005 3:14 pm    Post subject: Reply with quote

the answer: STATICALLY RETAINED LIBRARIES.

the need to perform redundant compilations to purge the system of statically retained libraries is a well established fact. those who understand the nature of the problem accept the need for redundant compilation. those who do not understand the nature of the problem tend to be the ones who start agruments about it.

if the guide doesn't suit your needs, you don't have to use it. but please, don't use your theoretical explanations to try to prove that the guide is wrong. over 100,000 people have installed using this method. it started off in theory using methods similar to what you are suggesting, and it has refined to its current state of revision by trial and error. the guide is written the way it is written because that method results in a system that works reliably. the suggestions that you are arguing would result in a system that would not work reliably.

please try to accept the fact that the Guide is written the way it is because this is the way that you have to do it. please don't argue that the Guide needs to be changed just because you don't fully understand what the Guide is doing. we've had 100,000+ test builds refine the installation method, and we won't consider changing it just because a couple of people who don't understand our methods start an argument about it.

the reasons for the steps are clearly outlined in the hundreds of pages of posts in the multiple threads related to this installation method. if you don't understand what is being done and why it is being done, please don't ask us to explain it for you. everything has already been well documented, and all that you need to do is read the threads to understand the logic.

best of luck.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Jul 16, 2005 3:16 pm    Post subject: Reply with quote

old versions of gcc used to pull in libstdc++-v3 as a dependency. new ones don't. the toolkit build fails if you fail to install libstdc++, so the step has been added manually. there's your answer.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Dark_Cloud
n00b
n00b


Joined: 29 Jun 2003
Posts: 27

PostPosted: Sat Jul 16, 2005 3:42 pm    Post subject: Reply with quote

Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it.

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.

thanks for guide and sorry about any disagreement

cheers :D
_________________
Powerred by Gentoo Linux 2005.0
2.6.12-ck4 i686 AMD Athlon(TM) XP 2600+
GCC 3.4.4, glibc 2.3.5 (NPTL)

E17 cuz it's CUTE and FAST! Just Get-E
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Sun Jul 17, 2005 6:50 am    Post subject: Reply with quote

Dark_Cloud wrote:
Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it.

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.

thanks for guide and sorry about any disagreement

cheers :D


Ok! the Author says that the reasons behind operating "emerge - system", in the old guide, and "emerge -e system && emerge -e system", in the new guide have already been explained in a lot of different places, doesn't He?

With this information, have you Dark_Cloud found out where the subject is treated and explained? I'm still searching but I don't find anything closely related to that subject.

I'm sorry too about his disagreement but I think he could answer to this special question that I don't see is treated anywhere. Because He asks in his guide to communicate him suspicious bugs this is exactly what we have done, I suppose... Obviously this is not what he meant.

However, just for people that "dont blindly follow what people say", like Dark_Cloud, this is my personl experience:

I have run the first "emerge -e system", then I copied in my home directory some important executables (like Bash) that were emerged at this first round. After I run "md5sum" on them and saved the hashes. Then I run again "emerge -e system", as it is stated in the new guide we are discussing about. At the end I used both "diff" and "md5sum" on the same files I had saved before. As everyone can imagine there was no difference between those file.

I must conclude there is absolutely no need to run "emerge -e system" twice, one after another, as it is stated in the new guide.

Notwithstanding what the author says I like his guide 8) and I thank him for providing it, but I will continue to use it the way I have expalained here, because I see those redundances.

I will continue to use it this way at least until someone is able to explain carefully why in the old one (gcc-3.4.3) we read and need only one "emerge -e system" while in the latest (gcc-3.4.4) we read and need "emerge -e system && emerge -e system".

None has yet provided any answer for a so simple question.

PS.: With a little trick I was able to "emerge -e system" without that old libstdc++ that no one needs. But this is another story...
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Jul 17, 2005 4:13 pm    Post subject: Reply with quote

Dark_Cloud wrote:
Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it.

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested)


Nope. The information about performing two emerge -e systems is in the 3.4.3 version of the Guide. You just haven't read the entire thread.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Jul 17, 2005 4:51 pm    Post subject: Reply with quote

kueitao wrote:
Dark_Cloud wrote:
Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it.

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.

thanks for guide and sorry about any disagreement

cheers :D


Ok! the Author says that the reasons behind operating "emerge - system", in the old guide, and "emerge -e system && emerge -e system", in the new guide have already been explained in a lot of different places, doesn't He?

With this information, have you Dark_Cloud found out where the subject is treated and explained? I'm still searching but I don't find anything closely related to that subject.

I'm sorry too about his disagreement but I think he could answer to this special question that I don't see is treated anywhere. Because He asks in his guide to communicate him suspicious bugs this is exactly what we have done, I suppose... Obviously this is not what he meant.

However, just for people that "dont blindly follow what people say", like Dark_Cloud, this is my personl experience:

I have run the first "emerge -e system", then I copied in my home directory some important executables (like Bash) that were emerged at this first round. After I run "md5sum" on them and saved the hashes. Then I run again "emerge -e system", as it is stated in the new guide we are discussing about. At the end I used both "diff" and "md5sum" on the same files I had saved before. As everyone can imagine there was no difference between those file.

I must conclude there is absolutely no need to run "emerge -e system" twice, one after another, as it is stated in the new guide. (emphasis added)

Notwithstanding what the author says I like his guide 8) and I thank him for providing it, but I will continue to use it the way I have expalained here, because I see those redundances.

I will continue to use it this way at least until someone is able to explain carefully why in the old one (gcc-3.4.3) we read and need only one "emerge -e system" while in the latest (gcc-3.4.4) we read and need "emerge -e system && emerge -e system".

None has yet provided any answer for a so simple question.

PS.: With a little trick I was able to "emerge -e system" without that old libstdc++ that no one needs. But this is another story...


sorry to disappoint you guys, but my purpose here is not to provide free personalized tutorial services for everyone who isn't up to speed -- my purpose here is to write-up an installation method that will work if you follow it -- nothing more.

the Guide works as it is written. if you don't think that steps are necessary, nobody's forcing you to perform them. you just need to realize that if you choose not to follow the Guide and your system breaks, then you get to keep the pieces. you shouldn't come back here looking for support. there's nothing rude about my telling you that.

i know that this will disappoint you, but i am not going to comb through the threads to look for hyperlinks to tutor you on the things that you need to know as a prerequisite for using the Guide. i just don't have the time. many people who haven't been up to speed have just chosen to accept the Guide for what it is, and follow it, even though they may not fully understand what they are doing. i find it a little surprising that some people who are in the same boat of inexperience would take the opposite tack and start an argument that is founded upon a lack of understanding on their part.

unfortunately, knowledge requires study and there's no shortcut in obtaining knowledge. as a practical matter, you're asking about one of the most esoteric problems that are encountered in building Gentoo -- why Gentoo doesn't work the way it is supposed to work, and what needs to be done to fix the problem. these are the kind of problems that only the most experienced Gentoo users are very familiar with. even though i've spent alot of time using my experience to write the Guide to help people , i don't have enough time to personally educate everyone on the forums to bring them up to my level of expertise on this subject. besides, i think that most users are looking for a quick and dirty answer and wouldn't want to spend the time that it would take to learn everthing that they need to know to really become up to speed.

if you are interested in learning, i have provided you with keywords that you can use with the board's SEARCH function to find threads that contain the information that you need to know to get you started. at this point, it is up to you to make the choice of performing the search and reading the information or not performing the search and not reading the information.

if you choose to do the search and find the information, then eventually your questions will be answered by your reading. if you choose not to do the search, you won't find the information and this will be a case of my leading a horse to water, only to find that he doesn't want to drink. that's as far as i can go, as i don't have the time to spoon-feed everyone who doesn't understand the nature of the problem with statically retained libraries.

suffice it to say that there's a difference between the theory of how Gentoo/GCC/portage are supposed to work in theory, and how they actually perform in practice. many people have already made theoretical arguments like yours about how the install should work -- only to find that they run into problems. this Guide has been designed from practical experience to circumvent those problems. experienced Gentoo users are expected to understand the concept, and that is one of the reasons that the warnings at the beginning of the Guide state that its for advanced users only,

if the logic of the Guide doesn't make sense to you, then this Guide is not appropriate for your level of expertise. i'm not trying to be snooty by saying that, those are just the facts and maybe the Gentoo Installation Handbook would be better suited to your needs. in the final analysis, you have the choice to follow the guide or not to follow the Guide. nobody's forcing you to follow it. i find it amusing, though, that you are so vehement in your denial that information exists just because you weren't able to find it.

again, my apologies for providing free support services that aren't up to your expectations. unfortunately i don't have the time to tutor everyone that comes along on the forums. if you still need more information about this, i would focus on the posts by @robmoss, @moocha and @bobp in the Portage & Programming forum that relate to properly rebuilding the toolkit. if you still have trouble, perhaps you should start a thread there asking why its sometimes necessary to perform emerge -e system twice. i'm sure that there are plenty of people who could help.

have fun. :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Dark_Cloud
n00b
n00b


Joined: 29 Jun 2003
Posts: 27

PostPosted: Mon Jul 18, 2005 3:13 pm    Post subject: Reply with quote

Dark_Cloud wrote:

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested)


I didnt read the entire thread (gcc-3.4.3), the fact is that i read the guide, as i said! I wanted to use the gcc-3.4.4 so, i just read its thread (fully)

Bob P wrote:
i know that this will disappoint you, but i am not going to comb through the threads to look for hyperlinks to tutor you on the things that you need to know as a prerequisite for using the Guide. i just don't have the time. many people who haven't been up to speed have just chosen to accept the Guide for what it is, and follow it, even though they may not fully understand what they are doing. i find it a little surprising that some people who are in the same boat of inexperience would take the opposite tack and start an argument that is founded upon a lack of understanding on their part.


i dont consider myself an experienced gentoo, still have many things to learn... but the statically retained libraries problem was something i really could link with the two emerge -e system, just wanted you to ensure it. Follow something i can not understand is a thing i will not do, one of the reasons i use linux is because i can understand what it do. Inexperience of my part? maybe, but im here to get the knowledge, no one knows everything.

cheers :D
_________________
Powerred by Gentoo Linux 2005.0
2.6.12-ck4 i686 AMD Athlon(TM) XP 2600+
GCC 3.4.4, glibc 2.3.5 (NPTL)

E17 cuz it's CUTE and FAST! Just Get-E
Back to top
View user's profile Send private message
Dark_Cloud
n00b
n00b


Joined: 29 Jun 2003
Posts: 27

PostPosted: Mon Jul 18, 2005 3:29 pm    Post subject: Reply with quote

the answer to the emerge -e system && emerge -e system related questions will be found at the other guide Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.3

for an example of problem take a look at the second page, @moocha and read @Bob P's reply

cheers :D
_________________
Powerred by Gentoo Linux 2005.0
2.6.12-ck4 i686 AMD Athlon(TM) XP 2600+
GCC 3.4.4, glibc 2.3.5 (NPTL)

E17 cuz it's CUTE and FAST! Just Get-E
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Jul 18, 2005 4:33 pm    Post subject: Reply with quote

this reply will get the Blue Treatment so that its easy for other people to find.

one thing that really helped me understand the toolkit build order from a theoretical standpoint is the linux from scratch documentation. but even that only gives theoretical considerations about why particular packages should be built in any particular order. it doesn't really address the somewhat convoluted way that we're building Gentoo because Portage doesn't build things in the proper order. redundant system/world compilations are the textbook way to address this problem via a brute-strength approach.

many new users have focused upon the fact that Package A gets compiled X number of times, as if the number of compilations is some sort of indictment of the building method. these people tend to miss the nuances about why you need to use the same version of the compiler to build itself -- the compiler that was used to build the compiler that builds their compiler needs to be the same compiler -- and how much redundant compiling is necessary to make that happen. :? granted, it does seem somewhat rediculous, but it really isn't.

if you were to read robmoss' posts about how to rebuild the system, he would suggest that you do the following every time that a major toolkit component is upgraded:


Code:
emerge -e system && emerge -e system && emerge -e world && emerge -e world


that approach is necessary because Portage does not build things in the proper order, and you have to make multiple passes in compiling to assure that packages are compiled against the proper packages. the logic behind the need for each step has already been beaten to death in the Stage 1/3 threads, so i won't reiterate it here.

in the Stage 1/3 Guide, I've tried to trim-down the total compiling time in comparison to the robmoss method, so that only the things that really need to be compiled are compiled. that's why we build the toolkit first (redundantly for the reasons stated earlier) and then use a properly built toolkit to perform two emerge -e systems to purge all remnants of code generated by an obsolete compiler from the system. then, when the system packages are properly built, the world files are populated and you only have to build them once instead of twice. this approach is alot quicker than the robmoss approach (especially if you have alot of world packages like X), and accomplishes the same thing in much less time. experience has shown that trying to cut out one of the emerge -e systems (like i did in previous versions of the Guide) just don't work -- the toolkit is never built properly failures inevitably result.

rebuilding a system toolkit is a very difficult procedure to get right. traditionally, you need to bootstrap in order to do this properly, especially if you are changing architecture or chost specifications. unfortuantely, bootstrapping into the testing branch in Gentoo is a risky venture at best, not to mention the circular dependency problems that are often encountered with Stage 1 installs. The Stage 1/3 method solves all of those problems at the expense of taking an awful lot of time to complete.

the warning in the preface to the Guide specifically cautions the user the time commitment that is required to perform this install properly. no, it wasn't a joke, and yes, every step is really necessary for the system to perform with integrity.

hth.

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Mon Jul 18, 2005 6:50 pm    Post subject: Reply with quote

Dark_Cloud wrote:
the answer to the emerge -e system && emerge -e system related questions will be found at the other guide Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.3

for an example of problem take a look at the second page, @moocha and read @Bob P's reply

cheers :D


Thank you. Now that I have just found it I cannot disagree anymore with that logic. I'm sorry I couldn't understand that reading the entire thread on installing with gcc-3.4.3 was essential to fully comprehend those mechanisms. It's my fault I supposed that only the guide itself on gcc-3.4.3, to which anyway I didn't give much attention because I was trying to install with gcc-3.4.4, was enough to make assumptions on how many "emerge -e system" were needed.

Cheers.
Back to top
View user's profile Send private message
kueitao
Apprentice
Apprentice


Joined: 22 Jan 2005
Posts: 241

PostPosted: Mon Jul 18, 2005 7:02 pm    Post subject: Reply with quote

Bob P wrote:
this reply will get the Blue Treatment so that its easy for other people to find


[cut some lines]

Bob P wrote:

Code:
emerge -e system && emerge -e system && emerge -e world && emerge -e world


... that approach is necessary because Portage does not build things in the proper order ...


[cut some more lines]

Thank you for the above quoted code and your detailed explanation on the subject. Now it's all very clear (also with contribution of the whole reading of "installation 1/3 with gcc-3.4.3". As I wrote in the last post, I'm sorry I couldn't understand I should had read the whole thread, not stopping at the end of the guide. :oops:

Regards.
Back to top
View user's profile Send private message
teilo
Apprentice
Apprentice


Joined: 20 Jun 2003
Posts: 276
Location: Minneapolis, MN

PostPosted: Mon Jul 18, 2005 7:44 pm    Post subject: Reply with quote

Shouldn't you be including an emerge linux-headers before rebuilding glibc?
_________________
Teilo who is called Teilo
Back to top
View user's profile Send private message
-=GGW=- $ol!d $n4>|e
Veteran
Veteran


Joined: 12 Apr 2004
Posts: 1614
Location: USA

PostPosted: Mon Jul 18, 2005 11:54 pm    Post subject: Reply with quote

YOU sir!, are a god among men. :)
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Tue Jul 19, 2005 12:02 am    Post subject: Reply with quote

teilo wrote:
Shouldn't you be including an emerge linux-headers before rebuilding glibc?


why?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Tue Jul 19, 2005 12:10 am    Post subject: Reply with quote

wow, i just did a quick glance at the Documentation Tips & Tricks forum. It seems that the 3 versions of the Stage 1/3 Guides have reached a total viewing of 125,432 page views, and the support threads have reached a total of 84,031 page views, for a total of 209,463 page views (not counting any of the Jackass! threads).

the only other installation guide that comes close is ali3nx's excellent Stage 1 tut, currently at 118,584 page views.

who would have thought that this installation method would have caught on like wildfire?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Tue Jul 19, 2005 12:13 am    Post subject: Reply with quote

Yea, verily, it is a like unto a force of nature.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 2 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum