----- Forwarded message from Martin Pool <[EMAIL PROTECTED]> ----- From: Martin Pool <[EMAIL PROTECTED]> Subject: Re: distcc Date: Mon, 17 Nov 2003 14:20:56 +1100 To: Jack Pavlovsky <[EMAIL PROTECTED]> User-Agent: Mutt/1.5.4i
On 20 Oct 2003, Jack Pavlovsky <[EMAIL PROTECTED]> wrote: > Compiling middleman (middle-man.sf.net), I've got an error: > gcc -c -g -O2 -pthread -Iinclude -I. -Wall -D_GNU_SOURCE -DVERSION=\"1.9\" > -DHAVE_CONFIG_H -D_REENTRANT pcre/get.c -o pcre/get.o > gcc -c -g -O2 -pthread -Iinclude -I. -Wall -D_GNU_SOURCE -DVERSION=\"1.9\" > -DHAVE_CONFIG_H -D_REENTRANT pcre/study.c -o pcre/study.o > gcc -o pcre/dftables -g -O2 -pthread -Iinclude -I. -Wall -D_GNU_SOURCE > -DVERSION=\"1.9\" pcre/dftables.c > gcc -c -g -O2 -pthread -Iinclude -I. -Wall -D_GNU_SOURCE -DVERSION=\"1.9\" > -DHAVE_CONFIG_H -D_REENTRANT pcre/pcre.c -o pcre/pcre.o > pcre/pcre.c:261:24: chartables.c: No such file or directory > distcc[26809] ERROR: compile on ivy failed > > Running make again goes thru this place (this chartables.c is > generated w/o compilation). Any way to circumvent this? (probably > there're several proggies that have Makefiles like that - wouldn't > be cool to leave things compiling for night only to find out that it > bailed out in the middle). Not sure, maybe it's only related to make > program itself. I use GNU make 3.80. I don't understand what you mean. You didn't show the command that compiles chartables.c. > I had installed distcc, and had runned distccd --daemon manually, at first. > It worked. Then I had installed it to my initscripts (the same command). > After reboot, the distccd processes are shown with ps, port 3632 is listened > to, but such error occurs. If I kill distccd, and run distccd --daemon > again, > it starts to work. As I wanted automatic startup, I tried to add it to > xinetd. > I added stuff to xinetd config, then restarted xinetd - it worked. But upon > reboot it doesn't work again (which is even more strange, since distccd is > started from xinetd only when the distcc connects to port). Kill xinetd and > run it again - stuff works. I couldn't comprehend this. Then the wild thing > came to mind: the only difference in the initscript-started distccd or > xinetd > and those I start in my shell is the environment - namely, the trouble was > with initscript PATH not containing /usr/local/bin (where my gcc and g++ > are), > while shell PATH contained it. I have set PATH in my initscripts, before > distccd > is run, to contain /usr/local/bin and it works now. I don't think anything > could (therefore should) be done in distccd code, but the stuff MUST be > documented as a serious caveat. E.g., in your installation guide, you should > write that initscript PATH should contain dir with gcc. Obviously many > people > have gcc in /usr/bin, so this problem wasn't spotted earlier, but it should > be fixed now. OK. The log file would probably have made this obvious. I just added this to the Problems page. Would this have helped you work it out? http://distcc.samba.org/problems.html#gcc-not-found -- Martin linux.conf.au -- Adelaide, January 2004 ----- End forwarded message ----- -- Martin linux.conf.au -- Adelaide, January 2004 __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc