the /usr/bin/gcc wrapper tool takes 3.5 seconds just to launch the real gcc. 3.5secons are on my sparc. I got reports up to 11 seconds on a mips machine and also 6 seconds on slower x86 machines. root@milka /home/joker # echo $PATH /sbin:/bin:/usr/sbin:/usr/local/bin:/usr/bin:/usr/local/sbin root@milka /home/joker # time /usr/bin/gcc -dumpversion 3.2.2 real 0m3.506s user 0m3.370s sys 0m0.140s As soon as the real gcc is in $PATH it is really fast. root@milka /home/joker # export PATH=$PATH:/usr/sparc-unknown-linux-gnu/gcc-bin/3.2 root@milka /home/joker # time /usr/bin/gcc -dumpversion 3.2.2 real 0m0.007s user 0m0.000s sys 0m0.000s One reason for /usr/bin/gcc is to have gcc working without having the special directory in PATH like after "su" (NOT "su -"). Since the wrapper reads the gcc-config stuff it should be fast without the path. Reproducible: Always Steps to Reproduce: 1. "su" (not "su -") 2. time /usr/bin/gcc -dumpversion 3. Add /usr/sparc-unknown-linux-gnu/gcc-bin/3.2 to path and redo 1. and 2. Actual Results: A huge delay measured between 3.5 and 11 seconds for a plain gcc -dumpversion and a really fast reaction with /usr/sparc-unknown-linux-gnu/gcc-bin/3.2 in path Expected Results: The wrapper should launch the real gcc fast even if the real gcc is not in PATH because it uses gcc-config settings directly and does not need to scan the HD. a "strace" shows does wait on the delay (it does not show any scanning or loop operations) "top" does show a "python" process eating 100% cpu during the delay. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 1984 root 14 0 2164 2164 1204 R 92.8 0.8 0:01 python Up to 11 seconds just to start gcc itself is too much. It will take ages on a Makefile based build where it starts gcc about 50 - 60 times.
*** This bug has been marked as a duplicate of 18766 ***
You need to source /etc/profile ?
Well i see the wrapper as solution for not having the PATH filled with /usr/sparc-unknown-linux-gnu/gcc-bin/3.2. The reason people "su" (not "su -") is to keep the old ENV around. And the /usr/bin/gcc wrapper is mostly there for this. If you have the full ENV loaded it would be pointless to have it since the system finds it with PATH. Anyway, sourcing the profile workarounds the delay but can be hardly called a fix to the problem.
Your understanding of the problem is flawed. It is the same as to say that running 'sudo fsck' as user, and then getting '-bash: fsck: command not found' is a bug.
We have just different point of views on this. I theres nothing "flawed". I work with "su" as root and don't want the unusual gcc path added in my /etc/login.defs. Yes i know theres a profile but i don't use it with su. I have been useing "su" for years and never "su -"
