[distcc] Re: gcc: installation problem, cannot exec `as'

Dimitri PAPADOPOULOS-ORFANOS papadopo at shfj.DECOY.cea.NOSPAM.fr
Tue May 13 19:10:26 GMT 2003


> The daemon function used by Red Hat in all its init scripts doesn't seem 
> to be modifying PATH. I've tried running an init script that contains:
>     daemon --user nobody 'set > /tmp/daemon.log'
> and file /tmp/daemon.log doesn't contain a modified PATH. But somehow 
> the PATH passed to distccd seems to contain /usr/local/bin, although I 
> can't explain why. I'll continue investigating this.

Actually this has to do with the init script, and the way it launches 

The init script /etc/init.d/distccd itself sees the following PATH:
I've checked this by inserting:
	echo $PATH >/tmp/distccd-path.txt
in the init script.

However distccd is seeing a different PATH depending on the way it's 
launched by the init script.

If distccd is launched using:
	daemon $DISTCCEXE --user nobody --daemon
then distccd sees the same PATH as the init script and all is well. The 
PATH is not trimmed by distccd and our whole setup runs smoothly.

On the other hand if distccd is launched using:
	daemon --user nobody $DISTCCEXE --daemon
then the PATH is somehow modified by the daemon function. distccd sees 
this PATH:
which is the PATH that is set by default for all accounts on Red Hat 
machines. The reason is obvious when you have look at the 'daemon' 
function, it spawns a shell:
	# A function to start a program.
	daemon() {
	  # And start it up.
	  if [ -z "$user" ]; then
	    $nice initlog -c "$*"
	    $nice initlog -c "su -s /bin/bash - $user -c \"$*\""

I now have a workaround, but I've nevertheless investigated a little bit 
further to have distcc fixed.

The next question is, what happens when distccd sees this PATH:

There are two 'cc' programs in this PATH. The first one is in '/usr/bin' 
and the second one is in '/usr/local/bin'. It seems something's going 
wrong with path trimming in such a configuration. The PATH shouldn't be 
trimmed because the first 'cc' encountered in the PATH is correct, so 
the second 'cc' encountered in the PATH has no effect.

Please find attached a patch that fixes this problem by replacing 
'continue' by 'break' in some cases.

-------------- next part --------------
--- src/util.c-	Tue May 13 19:36:42 2003
+++ src/util.c	Tue May 13 21:07:09 2003
@@ -256,8 +256,10 @@
          * cc.  It's possible people might hook some programs and not
          * others. */
         strcpy(buf + len, "/cc");
-        if (lstat(buf, &sb) == -1 || !S_ISLNK(sb.st_mode))
+        if (lstat(buf, &sb) == -1)
+	if (!S_ISLNK(sb.st_mode))
+	    break;
         if ((len = readlink(buf, linkbuf, sizeof linkbuf)) <= 0)
         linkbuf[len] = '\0';
@@ -265,7 +267,9 @@
          || (look_for_ccache_too && strstr(linkbuf, "ccache"))) {
             /* Set newpath to the part of the PATH past our match. */
             newpath = n;
-        }
+        } else
+	    break;
     if (newpath) {

More information about the distcc mailing list