I'm doing a gentoo install on a NFS-Root system (root doesn't matter; even /usr on NFS would hurt here). While watching a kernel compile take forever and ever on a machine that shouldn't take that long, i noticed that python kept appearring in "top" and wondered: WTF, the kernel build doesn't use python... so.. a little more watching and some greps for python in /usr/bin and I find that /usr/bin/gcc-config has a "python -c 'import portage; print portage.settings["CHOST"]'" in it. eek! Starting up python is an extreemly slow operation on NFS filesystems as it has to stat all of the .py, .pyc and .so modules and directories that it loads. Doing it once per gcc invocation is horrible. This slows down all compiles significantly; especially when /usr is on a network filesystem where latency bites on things like stat. Reproducible: Always Steps to Reproduce: 1. compile anything
emm .. i don't understand. gcc-config doesn't get called by gcc. and looking at gcc-config, i can't find any reference to python. which version of gcc-config are you using?
Further background, as it doesn't appear to happen all of the time. I was booted off of the small (stage1 only) gentoo 1.4 install CD on my p3. I did the following to chroot into my system for install: /etc/init.d/portmap start /etc/init.d/nfsmount start mount -t nfs -o tcp,posix,rsize=32768,wsize=32768 soap:/home/nfsroot /mnt/gentoo mount -o bind /proc /mnt/gentoo/proc mount -o bind /dev /mnt/gentoo/dev mount -o bind /tmp /mnt/gentoo/tmp chroot /mnt/gentoo /bin/bash env-update source /etc/profile (at this point i've chrooted to my nfsroot system; it should be the same as booting my own kernel directly into the system) Now.. go compile a kernel (sources already emerged earlier) cd /usr/src/linux make bzImage modules modules_install Notice how painfully slow the compile is going. yuck... On another text console, run top (the version on the gentoo cd; this console isn't chrooted). Notice that python appears in top with new PIDs quite frequently. Occasionally gcc-config shows up. Back on the make bzImage, it just shows normal kernel compile gcc commands being run. I also verified that this was happening by looking at a tcpdump of the NFS access; python and its many files were being statted and read repeatedly. A "strings /usr/bin/gcc | grep config" shows "/usr/bin/gcc-config --get-bin-path" as existing. When run, that prints "/usr/i686-pc-linux-gnu/gcc-bin/3.2" Ah ha. Now I think I see what was happening. To verify this, i wrote a little hello world and compiled it with root's PATH set to a simple "/sbin:/bin:/usr/sbin:/usr/bin" versus a fuller PATH that also included "/usr/i686-pc-linux-gnu/gcc-bin/3.2"... "strace -f" on both shows the one with the simpler path calling gcc-config. When gcc is run without the gcc-bin/X.Y in the search path, it calls /usr/bin/gcc-config --get-bin-path to figure out where to look for things. This *significantly* slowed down my nfsroot install process (the kernel compile alone took a couple hours on this 1.3ghz celery! not to mention the stage2+stage3 compile times). Even on a system not using a high stat/getattr latency root filesystem the gcc->gcc-config->python call would slow things down noticably. Now the question remains? Was this user (me) error? Or did my /etc/env.d/ not contain the correct gcc-bin path yet? I see that env-update should read /etc/env.d/05gcc and add this to the default path in /etc/profile.env which is run by /etc/profile. If I perhaps forgot to source /etc/profile I could see this occurring. I'll reboot off of the cd again and look around
Ok, I rebooted off the install CD and tried things with and without the source /etc/profile after the env-update in the chroot. My boot CD uses i586-pc-linux-gnu, while my installed system is setup to use i686-pc-linux-gnu. I believe this to be the source of the problem. The installed stage1.tar.bz2 included /usr/i586-pc-linux-gnu with its gcc 3.2.2 package. The stage2/stage3 emerges built and installed gcc 3.2.3 using my /etc/make.conf i686-pc-linux-gnu setting. But I did not run another env-update + source /etc/profile after emerge build and installed an updated gcc so my PATH at the time would still have pointed to the now disappearred i586 directory, causing gcc to need gcc-config. ***Suggested fix***: Please update the install.txt and related install instructions web pages to recommend doing a "env-update ; source /etc/profile" after the emerge that will likely have updated gcc on the system. I purposefully chose the i586 (x86?) simple install CD because it would run on all x86 PC hardware that I have or am likely to encounter even though most of my machines are much better.
Source /etc/profile.
The install.txt documentation should be updated to mention that doing an 'env-update ; source /etc/profile' after the emerge that updates gcc during install is a good idea to make the rest of the installation go faster.
Reassigning to docs-team to let them make the final determination regarding this issue, since the final solution appears to be something correctable via a documentation update.
Ehhh... the most optimal solution would be to "env-update && source /etc/profile" after every gcc emerge. Can't we automate a solution with pkg_postinst?
Is this still valid?
> the most optimal solution would be to "env-update && source /etc/profile" > after every gcc emerge. Can't we automate a solution with pkg_postinst? env-update is run by portage after every merge ... the user would only have to run `source /etc/profile` ... although we cannot modify the shell environment (the way bash works the user HAS to run SOMETHING), perhaps portage should be a little less affected by the environment ? or we just build the stages with the latest gcc versions and make users use that ? :)
exactly. because you can't do a 'source /etc/profile' for the user my suggested fix was just to recommend a source /etc/profile after the emerge that upgrades gcc in the installation instructions. i chose an i586 boot+install stage1 CD because it'll work on every computer i own. If I had used an i686 CD as most people probably do the problem wouldn't have occurred.
I can do that, but that doesn't solve it completely, as the gcc-update is part of a bunch of updates (the script/bootstrap.sh command, or emerge -u system) so that gcc will work "slow" during the rest of the updates.
Okay, I've updated the handbook regarding this. I'm not going to update the installation guide itself unless the handbook "Installing Gentoo" chapter isn't approved monday.
*** Bug 39162 has been marked as a duplicate of this bug. ***
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.
