[ccache] PRB: ccache directory not available
ccache: version 2.2 OS: Windows XP Professional cygwin: latest version Hello, first of all: we like ccache - its a great utlility - thanks a lot! We're using ccache to share compiler output between several people. All works fine - but if the ccache file server is not available - it would be nice if ccache compile local instead of generating an error message like the following: "ccache: failed to create //ad26080/ccache (No such host or network path)" Perhaps a new flag or environement variable or per default fall back to compile on local host without try fetching/saving files to ccache directory. I searched the man pages for such an option - but without success! Perhaps you can add a feature like this in the next release. best regards Heiko Elger ARBURG GmbH + Co Heiko Elger - Softwareentwicklung - / - Research and Development - Arthur-Hehl-Strasse D-72290 Lossburg Tel.: +49 (0) 7446 33-3659 Fax.: +49 (0) 7446 33-3365 mailto:heiko_elgernos...@arburg.com http://www.arburg.com Bitte entfernen Sie "NOSPAM" von der Email-Adresse Please remove "NOSPAM" from the email address
[ccache] ccache and distcc not hitting caches
Hello, I've just started to use this cool tool, but came up with the following problem: If I run ccache from my local machine I build a cache, where if I rebuild the same [unchanged] files, every file is hit in the cache. If I then set the following environment variable: CCACHE_PREFIX=distcc and re-run the same build [using ONLY my machine for building], not one file is hit in the cache. My setup is as follows: SunOS Release 5.8 Is there an option, or a patch I could use to remedy this problem? I would like to do simple builds locally, while more indepth builds using multiple hosts. Thanks, Mike
[ccache] About error: "failed to rename tmp files - No such file or directory"
Hi all,
I am using ccache (2.3) on Solaris 8 and using Sun Workshop 6 update 2
C++ compiler (5.3) for compilation.
If I have a file with extension .c then it seems to be cached after
compiling but if it has a .cc extension, I get the following message in
the ${CCACHE_LOGFILE}:
failed to rename tmp files - No such file or directory
Can you please help me?
Thanks,
Saket.
[ccache] Patch: Xcode compatibility
On Fri, Nov 21, 2003 at 03:28:32PM -0800, Sean Gies wrote: > 2. Added a check to the argument processing logic to handle this sort > of invocation: > /usr/share/bin/ccache /usr/bin/distcc /usr/bin/gcc-3.3 ... > > In order to handle multiple compiler versions, Xcode uses full paths to > invoke an explicit version of distcc or gcc. This confused ccache > because it thought the gcc-3.3 argument to distcc was a source file. Can you avoid that problem by using CCACHE_PREFIX? -Brian
[ccache] Patch: Xcode compatibility
Looks like mailman ate my attachment. Here's the patch again: < Here's a patch I created so that I can use ccache with Apple's Xcode > IDE. > > 1. Added more extensions to better support Objective-C and > Objective-C++. > > 2. Added a check to the argument processing logic to handle this sort > of invocation: > /usr/share/bin/ccache /usr/bin/distcc /usr/bin/gcc-3.3 ... > > In order to handle multiple compiler versions, Xcode uses full paths > to invoke an explicit version of distcc or gcc. This confused ccache > because it thought the gcc-3.3 argument to distcc was a source file. > > -Sean > > ___ > ccache mailing list > ccache@lists.samba.org > http://lists.samba.org/mailman/listinfo/ccache
[ccache] Patch: Xcode compatibility
Here's a patch I created so that I can use ccache with Apple's Xcode IDE. 1. Added more extensions to better support Objective-C and Objective-C++. 2. Added a check to the argument processing logic to handle this sort of invocation: /usr/share/bin/ccache /usr/bin/distcc /usr/bin/gcc-3.3 ... In order to handle multiple compiler versions, Xcode uses full paths to invoke an explicit version of distcc or gcc. This confused ccache because it thought the gcc-3.3 argument to distcc was a source file. -Sean
[ccache] Re: [distcc] Problem: reuse of ccache files regardless of creating with/without distcc
On 21 Oct 2003, heiko_el...@arburg.com wrote: > Hello, > > I have the following problem - I want to reuse the cached file regardless they > are created with or without distcc. > > I'm using distcc 2.11, Windows XP Professional, latest cygwin version. > > > I call make with ccache but without distcc - so the cache is full. > Delete the outputs and call again with ccache will - the objects are fetched > from the cache. > > Delete the outputs and call again with ccache and distcc - the objects are not > fetched from the cache but recreated. This is by design. The compiler is one of the variables used to check for cache hits. This helps make sure that if e.g the compiler is upgraded, files will be rebuilt. > 3.) compile with native gcc compiler using CCACHE and DISTCC (CCACHE_PREFIX) > make -B -j10 CC="ccache c:/programme/cygwin/bin/gcc" src/backoff.o > CCACHE_PREFIX=distcc & objdump -g src/backoff.o | head -n5 > ccache c:/programme/cygwin/bin/gcc -DHAVE_CONFIG_H -D_GNU_SOURCE -I./src > -DSYSCONFDIR="\"/usr/etc\"" > -DPKGDATADIR="\"/usr/share/distcc\"" -I./lzo -g -O2 -W -Wall -Wimplicit > -Wshadow -Wpointer-arith -W > cast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes > -Wmissing-prototypes -Wnested-exte > rns -o src/backoff.o -c src/backoff.c > > src/backoff.o: file format pe-i386 > > /src/backoff.c: > typedef int32 int; > > As you see the output of the debug information (I think it's the path of the > source) is not the same! This is a known problem with gcc's debug information generator. http://distcc.samba.org/problems.html#gdb -- Martin linux.conf.au -- Adelaide, January 2004
[ccache] GNU ar 2.9-gnupro-99r1p1 crashed when using with ccache.
Folks, I am trying to use ccache 2.3 and I used 1.9 before. Nothing works for me now. The ar crashed on me with both 1.9 and 2.3 version of ccache. GNU bash, version 2.05a.0(3)-release (i686-pc-cygwin) Copyright 2001 Free Software Foundation, Inc. ccache version 2.3 Copyright Andrew Tridgell 2002 Released under the GNU GPL v2 or later sparc-elf-ar.exe -V GNU ar 2.9-gnupro-99r1p1 Copyright 1997, 1998, 1999 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Did anyone experience that? If my ar is too old, which version of ar should I use? Thanks. - - - - - - - Appended by PowerTV, Inc. - - - - - - - This e-mail and any attachments may contain information that is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
[ccache] [patch] fix DEPENDENCIES_OUTPUT with ccache
Hi, On Thu, 28 Aug 2003, Martin Pool wrote: > DEPENDENCIES_OUTPUT is an alternative way to get Makefile-style > dependencies used by some Makefiles. > [...] Thanks, it really solves the problem with lilypond. In the mean time please let me mention: I've compiled openh323 (version 1.12.2 with gcc 3.3.1) and measured that ccache gave a 38x(!!!) speedup. There were even some files which took about a quarter of our to compile on my 375Mhz Celeron, but ccache fetched them in roughly one second. :-))) bye, Egmont
[ccache] [patch] better temporary filenames for ccache
This patch makes ccache's temporary filename include the basename of the
original file. This means that when ccache is used in conjunction with
distcc, you can see meaningful names in the distcc monitor rather than
just tmp.stdout.vexed.1234. It's much nicer.
Index: ccache.c
===
RCS file: /data/cvs/ccache/ccache.c,v
retrieving revision 1.80
diff -u -c -r1.80 ccache.c
*** ccache.c7 Mar 2003 12:09:19 - 1.80
--- ccache.c3 Sep 2003 03:02:50 -
***
*** 240,246
struct stat st;
int status;
int nlevels = 2;
!
if ((s = getenv("CCACHE_NLEVELS"))) {
nlevels = atoi(s);
if (nlevels < 1) nlevels = 1;
--- 249,257
struct stat st;
int status;
int nlevels = 2;
! char *input_base;
! char *tmp;
!
if ((s = getenv("CCACHE_NLEVELS"))) {
nlevels = atoi(s);
if (nlevels < 1) nlevels = 1;
***
*** 309,316
}
}
/* now the run */
! x_asprintf(&path_stdout, "%s/tmp.stdout.%s.%s", cache_dir,
tmp_string(),
i_extension);
x_asprintf(&path_stderr, "%s/tmp.cpp_stderr.%s", cache_dir,
tmp_string());
--- 320,336
}
}
+ /* ~/hello.c -> tmp.hello.123.i */
+ if ((tmp = strrchr(input_file, '/')) != NULL)
+ input_base = x_strdup(tmp + 1);
+ else
+ input_base = x_strdup(input_file);
+ if ((tmp = strchr(input_base, '.')) != NULL)
+ *tmp = 0;
+
/* now the run */
! x_asprintf(&path_stdout, "%s/%s.tmp.%s.%s", cache_dir,
! input_base, tmp_string(),
i_extension);
x_asprintf(&path_stderr, "%s/tmp.cpp_stderr.%s", cache_dir,
tmp_string());
--
Martin
[ccache] RE: [distcc] Fw: [NFS] nfs/mmap/rename file corruption
Hi Martin, Fantastic -- it solved my problem with the corrupted object files. Since the exports(5) manpage recommends using no_subtree_check for rapidly changing filesystems anyway, this is not such a bad solution. Thanks, -- Gavrie . > -Original Message- > From: Martin Pool [mailto:m...@sourcefrog.net] > Sent: Thursday, August 28, 2003 5:18 > To: dis...@lists.samba.org; ccache@lists.samba.org > Subject: [distcc] Fw: [NFS] nfs/mmap/rename file corruption > > > In summary: to make ccache work safely on an NFS filesystem, the > filesystem must be exported with no_subtree_check. Otherwise data can > be lost when it renames recently-written files. :-( > > > > -- > Begin forwarded message: > > Date: 27 Aug 2003 21:37:38 -0400 > From: Trond Myklebust > To: Martin Pool > Cc: n...@lists.sourceforge.net > Subject: Re: [NFS] nfs/mmap/rename file corruption > > > > " " == Martin Pool writes: > > > - ccache runs distcc with output to a temporary file > > - distcc opens, mmaps, writes to, munmaps, and closes the > temporary >file > > - distcc exits > > - ccache renames the temporary file to its proper location in > the >ccache > > - ccache opens the file read only, and reads from it > > Is this a rename from one directory to the other? If so, are you using > the 'no_subtree_check' option on the server? Without the latter option > enabled, I would indeed expect the behaviour that you describe. > > Cheers, > Trond > > > -- > Martin > __ > distcc mailing listhttp://distcc.samba.org/ > To unsubscribe or change options: > http://lists.samba.org/cgi-bin/mailman/listinfo/distcc > >
[ccache] [patch] fix DEPENDENCIES_OUTPUT with ccache
DEPENDENCIES_OUTPUT is an alternative way to get Makefile-style
dependencies used by some Makefiles.
Unfortunately when cc is invoked as separate cpp and cc1 passes, you
get dependencies for both of them.
This patch should fix it, please apply:
Index: ccache.c
===
RCS file: /data/cvs/ccache/ccache.c,v
retrieving revision 1.80
diff -u -c -r1.80 ccache.c
*** ccache.c7 Mar 2003 12:09:19 - 1.80
--- ccache.c28 Aug 2003 04:39:53 -
***
*** 4,9
--- 4,10
The idea is based on the shell-script compilercache by Erik Thiele
Copyright (C) Andrew Tridgell 2002
+Copyright (C) Martin Pool 2003
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
***
*** 153,158
--- 154,167
args_add(args, "-o");
args_add(args, tmp_hashname);
+
+ /* Turn off DEPENDENCIES_OUTPUT when running cc1, because
+* otherwise it will emit a line like
+*
+* tmp.stdout.vexed.732.o: /home/mbp/.ccache/tmp.stdout.vexed.732.i
+*
+* unsetenv() is on BSD and Linux but not portable. */
+ putenv("DEPENDENCIES_OUTPUT");
if (getenv("CCACHE_CPP2")) {
args_add(args, input_file);
--
Martin
[patch] [ccache] don't cache distcc errors
Please apply:
Index: ccache.c
===
RCS file: /data/cvs/ccache/ccache.c,v
retrieving revision 1.80
diff -u -c -r1.80 ccache.c
*** ccache.c7 Mar 2003 12:09:19 - 1.80
--- ccache.c28 Aug 2003 02:58:50 -
***
*** 871,876
--- 871,899
return 0;
}
+
+ /* Make a copy of stderr that will not be cached, so things like
+ * distcc can send networking errors to it. */
+ int setup_uncached_err(void)
+ {
+ char *buf;
+ int uncached_fd;
+
+ uncached_fd = dup(2);
+ if (uncached_fd == -1) {
+ fatal("dup(2) failed");
+ }
+
+ /* leak a pointer to the environment */
+ x_asprintf(&buf, "UNCACHED_ERR_FD=%d", uncached_fd);
+
+ if (putenv(buf) == -1)
+ fatal("putenv failed");
+
+ return 0;
+ }
+
+
int main(int argc, char *argv[])
{
cache_dir = getenv("CCACHE_DIR");
***
*** 879,884
--- 902,909
}
cache_logfile = getenv("CCACHE_LOGFILE");
+
+ setup_uncached_err();
/* check if we are being invoked as "ccache" */
if (strlen(argv[0]) >= strlen(MYNAME) &&
--
Martin
[ccache] [PATCH] nfs/mmap/rename file corruption
Please apply: *** ccache.yo 17 Feb 2003 00:46:43 - 1.22 --- ccache.yo 28 Aug 2003 02:57:26 - *** *** 302,307 --- 302,313 it() ccache avoids a double call to cpp on a cache miss ) + manpagesection(BUGS) + + When the cache is stored on an NFS filesystem, the filesystem must be + exported with the bf(no_subtree_check) option to make renames between + directories reliable. + manpagesection(CREDITS) Thanks to the following people for their contributions to ccache On Thu, 28 Aug 2003 12:17:39 +1000 Martin Pool wrote: > In summary: to make ccache work safely on an NFS filesystem, the > filesystem must be exported with no_subtree_check. Otherwise data can > be lost when it renames recently-written files. :-( > > > > -- > Begin forwarded message: > > Date: 27 Aug 2003 21:37:38 -0400 > From: Trond Myklebust > To: Martin Pool > Cc: n...@lists.sourceforge.net > Subject: Re: [NFS] nfs/mmap/rename file corruption > > > > " " == Martin Pool writes: > > > - ccache runs distcc with output to a temporary file > > - distcc opens, mmaps, writes to, munmaps, and closes the > temporary >file > > - distcc exits > > - ccache renames the temporary file to its proper location in > the >ccache > > - ccache opens the file read only, and reads from it > > Is this a rename from one directory to the other? If so, are you using > the 'no_subtree_check' option on the server? Without the latter option > enabled, I would indeed expect the behaviour that you describe. > > Cheers, > Trond > > > -- > Martin > ___ > ccache mailing list > ccache@lists.samba.org > http://lists.samba.org/mailman/listinfo/ccache -- Martin
[ccache] Fw: [NFS] nfs/mmap/rename file corruption
In summary: to make ccache work safely on an NFS filesystem, the filesystem must be exported with no_subtree_check. Otherwise data can be lost when it renames recently-written files. :-( -- Begin forwarded message: Date: 27 Aug 2003 21:37:38 -0400 From: Trond Myklebust To: Martin Pool Cc: n...@lists.sourceforge.net Subject: Re: [NFS] nfs/mmap/rename file corruption > " " == Martin Pool writes: > - ccache runs distcc with output to a temporary file > - distcc opens, mmaps, writes to, munmaps, and closes the temporary >file > - distcc exits > - ccache renames the temporary file to its proper location in the >ccache > - ccache opens the file read only, and reads from it Is this a rename from one directory to the other? If so, are you using the 'no_subtree_check' option on the server? Without the latter option enabled, I would indeed expect the behaviour that you describe. Cheers, Trond -- Martin
[ccache] lilypond doesn't compile with ccache (DEPENDENCIES_OUTPUT)
On Wed, 13 Aug 2003, Martin Pool wrote: > You can work around this in lilypond by using -MD -MF rather than > DEPENDENCIES_OUTPUT. It's clear but I rather worked it around in ccache since if ccache is not transparent for the application, it's a bug in ccache. I pay big price for this: due to my primitive workaround, my lilypond compilations are not cached. But it's not really a problem, I'm glad that I don't have to patch lilypond's source or disable ccache when compiling it. And I hope a clean and nice solution with caching the results will be included in ccache 2.3. > > Have a nice holiday, > > Thankyou! How did you know? :-) Just guessed it... it's summer anyway, isn't it? Oh, shit... IIRC most of the samba/ccache/distcc developers are in Australia, aren't they??? :-))) /me stupid... :-)) bye, Egmont
[ccache] lilypond doesn't compile with ccache (DEPENDENCIES_OUTPUT)
On 10 Aug 2003, Koblinger Egmont wrote: > ./out/axis.o: axis.cc include/axes.hh include/string.hh \ > include/arithmetic-operator.hh include/flower-proto.hh include/real.hh \ > include/string-handle.hh include/string-handle.icc \ > include/string-data.hh include/string-data.icc include/international.hh \ > include/compare.hh include/string.icc > > but when ccache is used, this file has one more line: > > ./out/axis.o: axis.cc include/axes.hh include/string.hh \ > include/arithmetic-operator.hh include/flower-proto.hh include/real.hh \ > include/string-handle.hh include/string-handle.icc \ > include/string-data.hh include/string-data.icc include/international.hh \ > include/compare.hh include/string.icc > ./out/axis.o: /home/egmont/.ccache/tmp.stdout.boci.5961.ii > > All the other *.dep files have a similar extra line appended which point > to some ccache-internal filename, which means that somehow ccache fails to > remain transparent for lilypond. > > The command that generates this .dep file is: > > DEPENDENCIES_OUTPUT="./out/axis.dep ./out/axis.o" c++ -c -DHAVE_CONFIG_H > -DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include > -I../flower/./out -O2 -finline-functions -g -O2 -finline-functions -g > -Wall -W -Wmissing-prototypes -Wconversion -o out/axis.o axis.cc Thankyou for reporting this. It looks like the problem is that DEPENDENCIES_OUTPUT is read by both cpp and cc1, so it gets dependencies for both .h->.i and .i->.o. Almost certainly you only want the first one. You can work around this in lilypond by using -MD -MF rather than DEPENDENCIES_OUTPUT. I think ccache (and distcc) ought to strip DEPENDENCIES_OUTPUT before invoking the compiler, so that you only get the first dependencies line. > Please take a look at this problem. It seems to me that ccache should fix > the DEPENDENCIES_OUTPUT files after running gcc itself, but real > developers should know it better than me :-) > > Another trivial workaround might be to let an existing DEPENDENCIES_OUTPUT > env variable simply imply CCACHE_DISABLE. A small patch is attached. I don't think such severe measures are needed. > Have a nice holiday, Thankyou! How did you know? :-) -- Martin
[ccache] lilypond doesn't compile with ccache (DEPENDENCIES_OUTPUT)
On Sunday 10 August 2003 09:13 am, Koblinger Egmont wrote: > Hi, > > lilypond 1.6.10 compiles fine without ccache, however it fails if ccache > is used. > > Get the source from ftp://ftp.lilypond.org/pub/LilyPond/v1.6/ and the two > patches from http://www.uhulinux.hu/~egmont/lilypond/ (these make it > compile with gcc 3.3). Do a "./configure; make". If ccache is not in your > PATH, it will succeed. > I know it might not be possible, but have you tried gcc < 3.3? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288
[ccache] lilypond doesn't compile with ccache (DEPENDENCIES_OUTPUT)
Hi,
lilypond 1.6.10 compiles fine without ccache, however it fails if ccache
is used.
Get the source from ftp://ftp.lilypond.org/pub/LilyPond/v1.6/ and the two
patches from http://www.uhulinux.hu/~egmont/lilypond/ (these make it
compile with gcc 3.3). Do a "./configure; make". If ccache is not in your
PATH, it will succeed.
When I use ccache (installed with symlinks as the manpage suggests as the
second way, no $CCACHE_* variables set, empty ~/.ccache dir at the
beginning) "make" fails with this error:
make[2]: *** No rule to make target `/home/egmont/.ccache/tmp.stdout.boci.5961.
make[2]: Leaving directory `/tmp/lilypond-1.6.10/flower'
make[1]: *** [out/lilypond] Error 2
rm out/parser.cc out/lexer.cc
make[1]: Leaving directory `/tmp/lilypond-1.6.10/lily'
make: *** [all] Error 2
Everything up to this message is the same as if I compile without ccache.
Strange, but if I type "make" once again, or start the complete procedure
from the very beginning (untarring the source and then ./configure; make)
but leave the old contents of ~/.ccache, then I get a different error
message ("collect2: ld returned 1 exit status" without any further
explanation).
There are a lot of .dep files generated at the early stage of "make". The
one that contains the string "/home/egmont/.ccache/tmp.stdout.boci.5961"
is flower/out/axis.dep. This file looks like this when compiling without
ccache:
./out/axis.o: axis.cc include/axes.hh include/string.hh \
include/arithmetic-operator.hh include/flower-proto.hh include/real.hh \
include/string-handle.hh include/string-handle.icc \
include/string-data.hh include/string-data.icc include/international.hh \
include/compare.hh include/string.icc
but when ccache is used, this file has one more line:
./out/axis.o: axis.cc include/axes.hh include/string.hh \
include/arithmetic-operator.hh include/flower-proto.hh include/real.hh \
include/string-handle.hh include/string-handle.icc \
include/string-data.hh include/string-data.icc include/international.hh \
include/compare.hh include/string.icc
./out/axis.o: /home/egmont/.ccache/tmp.stdout.boci.5961.ii
All the other *.dep files have a similar extra line appended which point
to some ccache-internal filename, which means that somehow ccache fails to
remain transparent for lilypond.
The command that generates this .dep file is:
DEPENDENCIES_OUTPUT="./out/axis.dep ./out/axis.o" c++ -c -DHAVE_CONFIG_H
-DSTRING_UTILS_INLINED -Iinclude -I./out -I../flower/include
-I../flower/./out -O2 -finline-functions -g -O2 -finline-functions -g
-Wall -W -Wmissing-prototypes -Wconversion -o out/axis.o axis.cc
I can't see yet how these .dep files are included from the Makefiles, but
I don't think it's important.
Please take a look at this problem. It seems to me that ccache should fix
the DEPENDENCIES_OUTPUT files after running gcc itself, but real
developers should know it better than me :-)
Another trivial workaround might be to let an existing DEPENDENCIES_OUTPUT
env variable simply imply CCACHE_DISABLE. A small patch is attached.
Have a nice holiday,
Egmont
Ps: gcc 3.3.1, ccache 2.2.
-- next part --
diff -urN ccache-2.2.orig/ccache.c ccache-2.2/ccache.c
--- ccache-2.2.orig/ccache.c2003-02-17 02:11:58.0 +0100
+++ ccache-2.2/ccache.c 2003-08-10 15:56:21.0 +0200
@@ -553,6 +553,17 @@
struct stat st;
char *e;
+ if (getenv("DEPENDENCIES_OUTPUT")) {
+ cc_log("environment variable DEPENDENCIES_OUTPUT is
unsupported\n");
+ stats_update(STATS_UNSUPPORTED);
+ failed();
+ }
+ if (getenv("SUNPRO_DEPENDENCIES")) {
+ cc_log("environment variable SUNPRO_DEPENDENCIES is
unsupported\n");
+ stats_update(STATS_UNSUPPORTED);
+ failed();
+ }
+
stripped_args = args_init(0, NULL);
args_add(stripped_args, argv[0]);
[ccache] [patch] allow distcc errors to be uncached
This patch makes ccache export a duplicate of stderr that is not
cached, by storing its file descriptor in $UNCACHED_ERR_FD. This
allows distcc to avoid having its error messages cached, which makes
sense because they are mostly 'transient' and only relate to the first
time a file is compiled.
For example, with this patch applied
$ export DISTCC_HOSTS=asdkajsdkjasd
$ ~/work/ccache/head/ccache distcc -c ./cases/hello.c -O2
distcc[28049] (dcc_connect_by_name) ERROR: failed to look up host
"asdkajsdkjasd": Unknown host
distcc[28049] (dcc_build_somewhere) Warning: failed to distribute to
asdkajsdkjasd, running locally instead
$ ~/work/ccache/head/ccache distcc -c ./cases/hello.c -O2
This avoids the potential of getting an error message referring to a
host that you think distcc shouldn't be using.
The last few distcc releases have been ready to support this. Please
merge it.
--- ccache.c.~1.80.~2003-07-14 11:05:31.0 +1000
+++ ccache.c2003-07-22 17:08:32.0 +1000
@@ -871,6 +871,29 @@ static int ccache_main(int argc, char *a
return 0;
}
+
+/* Make a copy of stderr that will not be cached, so things like
+ * distcc can send networking errors to it. */
+int setup_uncached_err(void)
+{
+char *buf;
+int uncached_fd;
+
+uncached_fd = dup(2);
+if (uncached_fd == -1) {
+fatal("dup(2) failed");
+}
+
+/* leak a pointer to the environment */
+x_asprintf(&buf, "UNCACHED_ERR_FD=%d", uncached_fd);
+
+if (putenv(buf) == -1)
+fatal("putenv failed");
+
+return 0;
+}
+
+
int main(int argc, char *argv[])
{
cache_dir = getenv("CCACHE_DIR");
@@ -880,6 +903,8 @@ int main(int argc, char *argv[])
cache_logfile = getenv("CCACHE_LOGFILE");
+setup_uncached_err();
+
/* check if we are being invoked as "ccache" */
if (strlen(argv[0]) >= strlen(MYNAME) &&
strcmp(argv[0] + strlen(argv[0]) - strlen(MYNAME), MYNAME) == 0) {
--
Martin
[ccache] ccache doesn't handle .i files
If I run ccache 2.2 on a .i file, it thinks it's not a C/C++ file and it doesn't cache it. This could be naively fixed by updating check_extension(), but it would be far better for ccache to know that it doesn't need to run cpp on such files. distcc does so. In particular this means that if ccache is run by distcc or distccd it will never hit. This is not a terribly big deal but might be nice to fix. -- Martin
[ccache] dbx "fix" utility not working with ccache
Hi, I am trying to use ccache. Everythings seems to be working fine. I am on a solaris 2.8 machine. I use dbx (through workshop) for debuggind. I am using the Sun compiler for the compiles. when I try to fix in dbx (fix quickly creates a new executable without full recompile. very useful for testing small changes), I get the following message : (dbx) fix main.c dbx: can't open source "/mnt/users/rmn/.ccache/tmp.stdout.zebra.21081.i", errno = 2 Has anyone tried using workshop and dbx with executables created through ccache? Any solutions to the problem I am having? Thanks __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
[ccache] CCACHE_PREFIX included in hash
Is CCACHE_PREFIX intentionally included in the hash? For my project it means that objects built locally never match objects built remotely with CCACHE_PREFIX=distcc, even though they are identical, and I'd like to avoid duplicate cache entries. If interested, I have a patch which avoids hashing it. Currently it is implemented as an alternate environment variable, CCACHE_NHPREFIX. -Brian
[ccache] PRB: using ccache and distcc: "multiple input files"
ccache: version 2.2 distcc: version 2.11 OS: Windows XP Professional cygwin: latest version Hello, I' using the calling distcc with the full compiler name cause of using different cross compiler versions for example compiling distcc distribution (using native gcc it's just the same behaviour): make -j10 CC="distcc c:/programme/cygwin/bin/gcc" --> All works fine If I use distcc and ccache make -j10 CC="ccache distcc c:/programme/cygwin/bin/gcc" --> I never will get any ccache results. See following log file snippet of ccache. here is a snippet of the ccache log file: - snip snip -- multiple input files (c:/programme/cygwin/bin/gcc and src/backoff.c) multiple input files (c:/programme/cygwin/bin/gcc and src/climasq.c) multiple input files (c:/programme/cygwin/bin/gcc and src/clinet.c) multiple input files (c:/programme/cygwin/bin/gcc and src/clirpc.c) multiple input files (c:/programme/cygwin/bin/gcc and src/compile.c) - snip snip -- I'm not sure what's wrong, but cause calling distcc without the full path name, all works fine, I assume that this is perhaps a problem of distcc. Using gcc is just an example - I want to use discc for cross compiling with the gnu cross compiler "ccpentium" from Wind River System. And cause we have serveral different compiler versions we have to use the full name of the compiler. I'm not sure why - but setting environment variable or make variable CCACHE_PREFIX=distcc all works fine. make -j10 CC="ccache distcc c:/programme/cygwin/bin/gcc" --> Error make -j10 CC="ccache distcc c:/programme/cygwin/bin/gcc" CCACHE_PREFIX=distcc --> OK But why? What's the difference? Perhaps anyone can give me a hint Mit freundlichen Gruessen best regards Heiko Elger ARBURG GmbH + Co Heiko Elger - Softwareentwicklung - / - Research and Development - Arthur-Hehl-Strasse D-72290 Lossburg Tel.: +49 (0) 7446 33-3659 Fax.: +49 (0) 7446 33-3365 mailto:heiko_elgernos...@arburg.com http://www.arburg.com Bitte entfernen Sie "NOSPAM" von der Email-Adresse Please remove "NOSPAM" from the email address
[ccache] ccache - -frepo
On 1 Oct 2003, andrew wrote:
> Hi,
>
> Should ccache always ignore compiles with (g++) -frepo, since object
> files might have to be rebuilt at link time, due to c++ template object
> code placement? I bypassed caching for -frepo'd source files so my
> template stuff would compile.
Yes, I think it should.
>
> :)
> andrew
>
> diff -Naur ccache-2.3/ccache.c ccache-2.3-nofrepo/ccache.c
> +++ ccache-2.3-nofrepo/ccache.c 2003-10-01 14:06:12.0 +1000
> @@ -630,6 +630,7 @@
>
> /* these are too hard */
> if (strcmp(argv[i], "-fbranch-probabilities")==0 ||
> + strcmp(argv[i], "-frepo") == 0 ||
> strcmp(argv[i], "-M") == 0 ||
> strcmp(argv[i], "-MM") == 0 ||
> strcmp(argv[i], "-x") == 0) {
>
>
>
> ___
> ccache mailing list
> ccache@lists.samba.org
> http://lists.samba.org/mailman/listinfo/ccache
--
Martin
[ccache] ccache - -frepo
Hi,
Should ccache always ignore compiles with (g++) -frepo, since object
files might have to be rebuilt at link time, due to c++ template object
code placement? I bypassed caching for -frepo'd source files so my
template stuff would compile.
:)
andrew
diff -Naur ccache-2.3/ccache.c ccache-2.3-nofrepo/ccache.c
--- ccache-2.3/ccache.c 2003-09-28 14:48:17.0 +1000
+++ ccache-2.3-nofrepo/ccache.c 2003-10-01 14:06:12.0 +1000
@@ -630,6 +630,7 @@
/* these are too hard */
if (strcmp(argv[i], "-fbranch-probabilities")==0 ||
+ strcmp(argv[i], "-frepo") == 0 ||
strcmp(argv[i], "-M") == 0 ||
strcmp(argv[i], "-MM") == 0 ||
strcmp(argv[i], "-x") == 0) {
[ccache] ccache 2.3 released
Koblinger Egmont writes: > The checksum generated by 2.3 is not compatible with previous ccache > versions. (I'm using ccache since 1.9 and it was always compatible.) > When I compile something, upgrade ccache from 2.2 to 2.3, and recompile it > again, there's no cache hit, everything is placed again. > > Is it a known issue (well, should be mentioned on the homepage) or a bug? This is known (at least by me!). Just about every release has changed the hash for some set of options, its just that this release changes the hash for the most commonly used set of options. I'll add a note to the home page. Cheers, Tridge
[ccache] ccache 2.3 released
Hi, > I've just released ccache 2.3. Grab it from http://ccache.samba.org/ The checksum generated by 2.3 is not compatible with previous ccache versions. (I'm using ccache since 1.9 and it was always compatible.) When I compile something, upgrade ccache from 2.2 to 2.3, and recompile it again, there's no cache hit, everything is placed again. Is it a known issue (well, should be mentioned on the homepage) or a bug? -- Egmont
[ccache] ccache 2.3 released
I've just released ccache 2.3. Grab it from http://ccache.samba.org/ Major changes: * Added CCACHE_UMASK option * Added support for compilation of .i files * Fixed bug with DEPENDENCIES_OUTPUT flag * Added support for more -Mx options * Added separate stderr channel for distcc * Improved test suite Cheers, Tridge
[ccache] Re: [distcc] ccache doesn't handle .i files
On Wed, 24 Sep 2003 ee...@gmx.net wrote: > + close(creat(path_stderr, 0644)); Should be 0666, the rest is the job of umask. -- Egmont
[ccache] Re: [distcc] ccache doesn't handle .i files
Huh?
--- ccache-new/ccache.c 2003-09-23 22:25:49.0 +0200
+++ ccache-new2/ccache.c2003-09-24 05:59:53.0 +0200
@@ -245,7 +245,6 @@
{
int i;
char *path_stdout, *path_stderr;
- char *command;
char *hash_dir;
char *s;
struct stat st;
@@ -341,9 +340,7 @@
} else {
copy_file(input_file, path_stdout);
- x_asprintf(&command, "touch %s", path_stderr);
- system(command);
- free(command);
+ close(creat(path_stderr, 0644));
}
/* if the compilation is with -g then we have to inlcude the whole of
the
preprocessor output, which means we are sensitive to line number
[ccache] Re: [distcc] ccache doesn't handle .i files
> + } else {
> + copy_file(input_file, path_stdout);
> + x_asprintf(&command, "touch %s", path_stderr);
> + system(command);
> + free(command);
> + }
Huh?
i know, it's been a while since i last did c. i'm sure there are
faster ways to provide the empty preprocessor error file, or maybe
it's not even needed if the hashing gets moved into the
conditional. i was just curious if it would be that hard to get it to
work, and it seemed to do when i tested it locally.
isidor
[ccache] Re: [distcc] ccache doesn't handle .i files
On 23 Sep 2003, ee...@gmx.net wrote:
> on Mon, 21 Jul 2003 23:52:45 -0700, Martin Pool wrote:
> >If I run ccache 2.2 on a .i file, it thinks it's not a C/C++ file and
> >it doesn't cache it.
> >
> >This could be naively fixed by updating check_extension(), but it
> >would be far better for ccache to know that it doesn't need to run cpp
> >on such files. distcc does so.
> >
> >In particular this means that if ccache is run by distcc or distccd it
> >will never hit.
> >
> >This is not a terribly big deal but might be nice to fix.
>
> imho it's a better way to combine ccache and distcc to ccache on the
> distcc hosts after distributing, as compiler upgrades are handled
> correctly this way.
That was what I meant by running it from distccd.
> maybe this will do(I know it's kludgy but to nicely implement it some
> redesign of ccache would be needed):
> @@ -64,19 +70,23 @@
> static struct {
> char *extension;
> char *i_extension;
> + int preprocess;
Okay.
> + if (preprocess) {
> + /* now the run */
> args_add(args, "-E");
> args_add(args, input_file);
> status = execute(args->argv, path_stdout, path_stderr);
> @@ -327,6 +339,12 @@
> failed();
> }
>
> + } else {
> + copy_file(input_file, path_stdout);
> + x_asprintf(&command, "touch %s", path_stderr);
> + system(command);
> + free(command);
> + }
Huh?
--
Martin
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/ccache/attachments/20030924/d47b8340/attachment.bin
[ccache] Re: [distcc] ccache doesn't handle .i files
on Mon, 21 Jul 2003 23:52:45 -0700, Martin Pool wrote:
If I run ccache 2.2 on a .i file, it thinks it's not a C/C++ file and
it doesn't cache it.
This could be naively fixed by updating check_extension(), but it
would be far better for ccache to know that it doesn't need to run cpp
on such files. distcc does so.
In particular this means that if ccache is run by distcc or distccd it
will never hit.
This is not a terribly big deal but might be nice to fix.
--
Martin
imho it's a better way to combine ccache and distcc to ccache on the
distcc hosts after distributing, as compiler upgrades are handled
correctly this way.
maybe this will do(I know it's kludgy but to nicely implement it some
redesign of ccache would be needed):
--- ccache/ccache.c 2003-09-23 20:09:54.0 +0200
+++ ccache-new/ccache.c 2003-09-23 22:25:49.0 +0200
@@ -43,6 +43,12 @@
/* the name of the file containing the cached object code */
static char *hashname;
+/* whether to do pre-processing */
+static int preprocess;
+
+/* the extension of the file before pre-processing */
+static const char *extension;
+
/* the extension of the file after pre-processing */
static const char *i_extension;
@@ -64,19 +70,23 @@
static struct {
char *extension;
char *i_extension;
+ int preprocess;
} extensions[] = {
- {"c", "i"},
- {"C", "ii"},
- {"m", "mi"},
- {"cc", "ii"},
- {"CC", "ii"},
- {"cpp", "ii"},
- {"CPP", "ii"},
- {"cxx", "ii"},
- {"CXX", "ii"},
- {"c++", "ii"},
- {"C++", "ii"},
- {NULL, NULL}};
+ {"c", "i", 1},
+ {"C", "ii", 1},
+ {"m", "mi", 1},
+ {"cc", "ii", 1},
+ {"CC", "ii", 1},
+ {"cpp", "ii", 1},
+ {"CPP", "ii", 1},
+ {"cxx", "ii", 1},
+ {"CXX", "ii", 1},
+ {"c++", "ii", 1},
+ {"C++", "ii", 1},
+ {"i", "i", 0},
+ {"ii", "ii", 0},
+ {"mi", "mi", 0},
+ {NULL, NULL, 0}};
/*
something went badly wrong - just execute the real compiler
@@ -235,6 +245,7 @@
{
int i;
char *path_stdout, *path_stderr;
+ char *command;
char *hash_dir;
char *s;
struct stat st;
@@ -309,11 +320,12 @@
}
}
- /* now the run */
x_asprintf(&path_stdout, "%s/tmp.stdout.%s.%s", cache_dir,
tmp_string(),
i_extension);
x_asprintf(&path_stderr, "%s/tmp.cpp_stderr.%s", cache_dir,
tmp_string());
+ if (preprocess) {
+ /* now the run */
args_add(args, "-E");
args_add(args, input_file);
status = execute(args->argv, path_stdout, path_stderr);
@@ -327,6 +339,12 @@
failed();
}
+ } else {
+ copy_file(input_file, path_stdout);
+ x_asprintf(&command, "touch %s", path_stderr);
+ system(command);
+ free(command);
+ }
/* if the compilation is with -g then we have to inlcude the whole of
the
preprocessor output, which means we are sensitive to line number
information. Otherwise we can discard line number info, which makes
@@ -536,6 +554,8 @@
if (strcmp(p, extensions[i].extension) == 0) {
p = getenv("CCACHE_EXTENSION");
if (p) return p;
+ extension = extensions[i].extension;
+ preprocess = extensions[i].preprocess;
return extensions[i].i_extension;
}
}
[ccache] patch to avoid empty stderr cache files
On Sat, Jun 07, 2003 at 11:29:51AM +0200, Koblinger Egmont wrote:
>
> Hi,
>
> > I noticed, however, that it generates a .stderr file in the cache
> > directory for each compiled file, even if there is no output on stderr.
> > This is a little bit wasteful -- we don't need the stderr file in the
> > very common case of the compiler not producing any warnings.
>
> Nice idea.
>
> Just one comment. It seems to me that you place the output file in the
> cache first and stderr later. This way if ccache is interrupted between
> these two steps it will result in a syntactically valid but false cache
> content (recompiling the same code will swallow stderr). So the stderr
> file should be placed first in the cache and the output afterwards.
Good point. I tried to think of edge conditions that might cause
problems, but obviously I missed this one.
Fortunately the fix is very simple, and exactly as you suggest.
Thanks!
Brian.
-- next part --
--- ccache.c~ Sun May 25 10:29:41 2003
+++ ccache.cMon May 26 19:31:19 2003
@@ -143,7 +143,7 @@
char *path_stderr;
char *tmp_stdout, *tmp_stderr, *tmp_hashname;
struct stat st1, st2;
- int status;
+ int status, fail;
x_asprintf(&tmp_stdout, "%s/tmp.stdout.%s", cache_dir, tmp_string());
x_asprintf(&tmp_stderr, "%s/tmp.stderr.%s", cache_dir, tmp_string());
@@ -209,17 +209,27 @@
x_asprintf(&path_stderr, "%s.stderr", hashname);
- if (stat(tmp_stderr, &st1) != 0 ||
- stat(tmp_hashname, &st2) != 0 ||
- rename(tmp_hashname, hashname) != 0 ||
- rename(tmp_stderr, path_stderr) != 0) {
- cc_log("failed to rename tmp files - %s\n", strerror(errno));
+
+fail = (stat(tmp_stderr, &st1) != 0);
+fail = fail || (stat(tmp_hashname, &st2) != 0);
+if (!fail) {
+if (st1.st_size == 0) {
+/* If the stderr file is empty, delete it to save an inode */
+unlink(tmp_stderr);
+} else {
+fail = fail || (rename(tmp_stderr, path_stderr) != 0);
+}
+}
+fail = fail || (rename(tmp_hashname, hashname) != 0);
+
+if (fail) {
+ cc_log("failed to rename tmp files (%s %s) - %s\n",
tmp_hashname, tmp_stderr, strerror(errno));
stats_update(STATS_ERROR);
failed();
}
cc_log("Placed %s into cache\n", output_file);
- stats_tocache(file_size(&st1) + file_size(&st2));
+ stats_tocache(file_size(&st1) + file_size(&st2), (st1.st_size == 0));
free(tmp_hashname);
free(tmp_stderr);
@@ -391,31 +401,28 @@
int ret;
struct stat st;
- x_asprintf(&stderr_file, "%s.stderr", hashname);
- fd_stderr = open(stderr_file, O_RDONLY);
- if (fd_stderr == -1) {
- /* it isn't in cache ... */
- free(stderr_file);
- return;
- }
-
- /* make sure the output is there too */
+ /* make sure the output is in the cache */
if (stat(hashname, &st) != 0) {
- close(fd_stderr);
- unlink(stderr_file);
- free(stderr_file);
return;
}
+
+/* check if stderr is too. If it isn't we
+ know that stderr must have been empty. */
+ x_asprintf(&stderr_file, "%s.stderr", hashname);
+ fd_stderr = open(stderr_file, O_RDONLY);
/* the user might be disabling cache hits */
if (first && getenv("CCACHE_RECACHE")) {
- close(fd_stderr);
- unlink(stderr_file);
+ if (fd_stderr != -1) {
+close(fd_stderr);
+unlink(stderr_file);
+
+}
free(stderr_file);
return;
}
- utime(stderr_file, NULL);
+ if (fd_stderr != -1) utime(stderr_file, NULL);
if (strcmp(output_file, "/dev/null") == 0) {
ret = 0;
@@ -432,8 +439,11 @@
if (ret == -1 && errno == ENOENT) {
cc_log("hashfile missing for %s\n", output_file);
stats_update(STATS_MISSING);
- close(fd_stderr);
- unlink(stderr_file);
+ if (fd_stderr != -1) {
+close(fd_stderr);
+unlink(stderr_file);
+}
+free(stderr_file);
return;
}
free(stderr_file);
@@ -469,9 +479,11 @@
cpp_stderr = NULL;
}
- /* send the stderr */
- copy_fd(fd_stderr, 2);
- close(fd_stderr);
+/* send the stderr, if applicable */
+if (fd_stderr != -1) {
+copy_fd(fd_stderr, 2);
+close(fd_stderr);
+}
/* and exit with the right status code */
if (first) {
@@ -813,7 +825,6 @@
/* the main program when not doing a comp
[ccache] patch to avoid empty stderr cache files
Hi, > I noticed, however, that it generates a .stderr file in the cache > directory for each compiled file, even if there is no output on stderr. > This is a little bit wasteful -- we don't need the stderr file in the > very common case of the compiler not producing any warnings. Nice idea. Just one comment. It seems to me that you place the output file in the cache first and stderr later. This way if ccache is interrupted between these two steps it will result in a syntactically valid but false cache content (recompiling the same code will swallow stderr). So the stderr file should be placed first in the cache and the output afterwards. cheers, Egmont
[ccache] patch to avoid empty stderr cache files
Hi all,
I was playing around with ccache on MacOS X recently, and its a pretty
cool utility.
I noticed, however, that it generates a .stderr file in the cache
directory for each compiled file, even if there is no output on stderr.
This is a little bit wasteful -- we don't need the stderr file in the
very common case of the compiler not producing any warnings.
Included is a patch that fixes up this problem. As well as saving
precious precious inodes, it should probably make things a tiny bit
faster -- directory tables will be smaller making namei faster, and we
turn a 'open, read, close' sequence into just open 'open' syscall.
I've tried it out compiling Camino (a gecko based brower) on OSX, and it
seems fine.
Cheers,
Brian Foley.
-- next part --
--- ccache.c~ Sun May 25 10:29:41 2003
+++ ccache.cMon May 26 19:31:19 2003
@@ -143,7 +143,7 @@
char *path_stderr;
char *tmp_stdout, *tmp_stderr, *tmp_hashname;
struct stat st1, st2;
- int status;
+ int status, fail;
x_asprintf(&tmp_stdout, "%s/tmp.stdout.%s", cache_dir, tmp_string());
x_asprintf(&tmp_stderr, "%s/tmp.stderr.%s", cache_dir, tmp_string());
@@ -209,17 +209,27 @@
x_asprintf(&path_stderr, "%s.stderr", hashname);
- if (stat(tmp_stderr, &st1) != 0 ||
- stat(tmp_hashname, &st2) != 0 ||
- rename(tmp_hashname, hashname) != 0 ||
- rename(tmp_stderr, path_stderr) != 0) {
- cc_log("failed to rename tmp files - %s\n", strerror(errno));
+
+fail = (stat(tmp_stderr, &st1) != 0);
+fail = fail || (stat(tmp_hashname, &st2) != 0);
+fail = fail || (rename(tmp_hashname, hashname) != 0);
+if (!fail) {
+if (st1.st_size == 0) {
+/* If the stderr file is empty, delete it to save an inode */
+unlink(tmp_stderr);
+} else {
+fail = fail || (rename(tmp_stderr, path_stderr) != 0);
+}
+}
+
+if (fail) {
+ cc_log("failed to rename tmp files (%s %s) - %s\n",
tmp_hashname, tmp_stderr, strerror(errno));
stats_update(STATS_ERROR);
failed();
}
cc_log("Placed %s into cache\n", output_file);
- stats_tocache(file_size(&st1) + file_size(&st2));
+ stats_tocache(file_size(&st1) + file_size(&st2), (st1.st_size == 0));
free(tmp_hashname);
free(tmp_stderr);
@@ -391,31 +401,28 @@
int ret;
struct stat st;
- x_asprintf(&stderr_file, "%s.stderr", hashname);
- fd_stderr = open(stderr_file, O_RDONLY);
- if (fd_stderr == -1) {
- /* it isn't in cache ... */
- free(stderr_file);
- return;
- }
-
- /* make sure the output is there too */
+ /* make sure the output is in the cache */
if (stat(hashname, &st) != 0) {
- close(fd_stderr);
- unlink(stderr_file);
- free(stderr_file);
return;
}
+
+/* check if stderr is too. If it isn't we
+ know that stderr must have been empty. */
+ x_asprintf(&stderr_file, "%s.stderr", hashname);
+ fd_stderr = open(stderr_file, O_RDONLY);
/* the user might be disabling cache hits */
if (first && getenv("CCACHE_RECACHE")) {
- close(fd_stderr);
- unlink(stderr_file);
+ if (fd_stderr != -1) {
+close(fd_stderr);
+unlink(stderr_file);
+
+}
free(stderr_file);
return;
}
- utime(stderr_file, NULL);
+ if (fd_stderr != -1) utime(stderr_file, NULL);
if (strcmp(output_file, "/dev/null") == 0) {
ret = 0;
@@ -432,8 +439,11 @@
if (ret == -1 && errno == ENOENT) {
cc_log("hashfile missing for %s\n", output_file);
stats_update(STATS_MISSING);
- close(fd_stderr);
- unlink(stderr_file);
+ if (fd_stderr != -1) {
+close(fd_stderr);
+unlink(stderr_file);
+}
+free(stderr_file);
return;
}
free(stderr_file);
@@ -469,9 +479,11 @@
cpp_stderr = NULL;
}
- /* send the stderr */
- copy_fd(fd_stderr, 2);
- close(fd_stderr);
+/* send the stderr, if applicable */
+if (fd_stderr != -1) {
+copy_fd(fd_stderr, 2);
+close(fd_stderr);
+}
/* and exit with the right status code */
if (first) {
@@ -813,7 +825,6 @@
/* the main program when not doing a compile */
static int ccache_main(int argc, char *argv[])
{
- extern int optind;
int c;
size_t v;
--- ccache.h~ Mon May 26 19:17:36 2003
+++ ccache.hMon May 26 19:
[ccache] FW: [patch] ccache makefile fix
On 17 Apr 2003, "Green, Paul" wrote: > Whoops, sent this to the wrong list initially. I hope the enclosed patch can > be applied to ccache. Thanks, applied. Have a good weekend! -- Martin
[ccache] FW: [patch] ccache makefile fix
Whoops, sent this to the wrong list initially. I hope the enclosed patch can
be applied to ccache.
Thanks
PG
-Original Message-
From: Green, Paul [mailto:paul.gr...@stratus.com]
Sent: Wednesday, April 16, 2003 9:43 AM
To: Samba Technical (E-mail)
Subject: [patch] ccache makefile fix
The following patch fixes the ccache Makefile.in to handle executable
suffixes. Turns out the configure script is already setting the necessary
substitutable variable (EXEEXT). Tested by me on Stratus VOS.
Thanks
PG
--
Paul Green, Senior Technical Consultant,
Stratus Technologies, Maynard, MA USA
Voice: +1 978-461-7557; FAX: +1 978-461-3610
Speaking from Stratus not for Stratus
-- next part --
diff -urpN old/ccache/Makefile.in new/ccache/Makefile.in
--- old/ccache/Makefile.in Tue Apr 15 21:37:31 2003
+++ new/ccache/Makefile.in Tue Apr 15 21:52:41 2003
@@ -9,16 +9,17 @@ installc...@install@
c...@cc@
cfla...@cflags@ -I.
+exee...@exeext@
OBJS= ccache.o mdfour.o hash.o execute.o util.o args.o stats.o \
cleanup.o snprintf.o unify.o
HEADERS = ccache.h mdfour.h
-all: ccache
+all: ccache$(EXEEXT)
docs: ccache.1 web/ccache-man.html
-ccache: $(OBJS) $(HEADERS)
+ccache$(EXEEXT): $(OBJS) $(HEADERS)
$(CC) $(CFLAGS) -o $@ $(OBJS)
ccache.1: ccache.yo
@@ -28,14 +29,14 @@ web/ccache-man.html: ccache.yo
mkdir -p man
yodl2html -o web/ccache-man.html ccache.yo
-install: ccache ccache.1
+install: ccache$(EXEEXT) ccache.1
${INSTALLCMD} -d $(DESTDIR)${bindir}
- ${INSTALLCMD} -m 755 ccache $(DESTDIR)${bindir}
+ ${INSTALLCMD} -m 755 ccache$(EXEEXT) $(DESTDIR)${bindir}
${INSTALLCMD} -d $(DESTDIR)${mandir}/man1
${INSTALLCMD} -m 644 ${srcdir}/ccache.1 $(DESTDIR)${mandir}/man1/
clean:
- /bin/rm -f $(OBJS) *~ ccache
+ /bin/rm -f $(OBJS) *~ ccache$(EXEEXT)
test: test.sh
./test.sh
[ccache] debugging ccache on shared nfs drive
Hello
Sorry i doesn't give up, because a have already feeled the power of ccache (
and distcc)
thanks for the reply in previous mails but it doesnt alway work, i did some
more tests to find out way not always it take it from the ccache.
i think i have the same problem like Enno Rehling with two debian machines,
but i am using the gentoo distro.
with gentoo are there two tools to auto compile and update the packages emerge
and ebuild.
if i use emerge package_x then the two pc's havent the same result so the
second time on the other machine the compiling doesn't come from the cacche.
if i use
ebuild package_x clean
ebuild package_x unpack
ebuild package_x compile
the same problem the second time no cache hit.
but if i do previous command a second time on the same machine yes then cache
hits. (so ccache is good configured)
the ccache stats are the same on the two machine so they share the same ccache
nfs maps
if i doesnt use the emerge or ebuild command no problem
that wil say compiling a kernel works perfect, the second time on a other
machine fast because it comes from the ccache.
if i compile manuel package_x after unpacking it with ebuild ( use make ) than
on the second pc also manual ( use make ) compiling al comes from the ccache
so ebuild en emerge do some strangs things and the ccache file arent the same
if i use ebuild, therefore i patches ccache to extend the CCACHE_LOGFILE with
extra data, sorry for the code its works but i'm not a expert in writing C
code.
ok this means that it is the gentoo tools emerge and ebuild who change some
things if they compile.
therefore an other test, i take two other machines and make a copy of the disk
to the second machine's disk and just rename the hostname and ip of corse, and
yes thats working fine, so it must works with the other gentoo machines to.
but how to find out what parameter make the difference.
my question ?
if somebody have time to check this quick patch that i use to debug with
parameters are supply with compiling please
this is some output form the CCACHE_LOGFILE
CCACHE args are: gcc -march=pentium -O3 -pipe -fomit-frame-pointer -Wall
-Wbad-function-cast -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmiss
ing-declarations -Wnested-externs -Winline daemon.c -c
CCACHE hashname: /nfs/ccache/6/3/14dd5656531f103d8990c53ac0be7e-20220
got cached result for daemon.o
so i see that the args are the same on the to machines and also see the ccache
hasname
because i not so a good C writer i ask to the ccache group is there someone
with some time to make a patch and maybe later standard in the sources of
ccache with a extra CCACHE_DEBUG_LOGFILE shell variable that print the most
parameters that make ccache to create a new ccache file or take it from ccache.
my patch for example just print the ccache argsv and the hashname, adding the
gcc size, gcc time ,... , ..., wil help to findout wich param is difference
and have to correct on the pc to make it take next time identical, so must
faster from ccache.
because the manual compiling on the to pc works fine, i think there is no
problem with include files or so, they must be the same includefiles otherwise
shouldnt the second time manuel compiling on the other machine takes it from
ccache.
I cannot do a pre-processor test with the -E options because the manuel
compiling is ok, and cant it implement in the gentoo tools.
on the forums on the gentoo site i do not find tips to this problem or how to
correct it.
thanks
Kris
-- next part --
*** ccache.c_origineel Mon Feb 17 02:11:58 2003
--- ccache.cTue Apr 8 23:12:18 2003
***
*** 757,764
--- 757,766
/* the main ccache driver function */
static void ccache(int argc, char *argv[])
{
+ int i;
+
/* find the real compiler */
find_compiler(argc, argv);
/* we might be disabled */
***
*** 769,779
--- 771,793
/* process argument list, returning a new set of arguments for
pre-processing */
process_args(orig_args->argc, orig_args->argv);
+ cc_log("CCACHE args are: ");
+ for (i=0;i
[ccache] sharing a cache
Enno Rehling wrote: > Anders Furuhed wrote: > >> Hi Enno, >> >> you get these misses only if different hosts are used? >> In that case, have you verified that the same compiler (its size and >> modification time) is used on the separate machines? > > > I'm using twoidentical compilers (gcc 2.95.4), both are debian > machines, freshly updated. And like I said, the output at least is > 100% identical, too. ccache seems to think the input is different, and > I'm no closer to figuring out why than I was yesterday. > Just to make sure what you mean by identical output: the resulting .o or the preprocessed output of gcc -E? If the preprocessed output is not identical for the two runs, there will be a cache miss even if the resulting .o files are identical. It may be helpful to turn on CCACHE_LOGFILE and try to see what ccache says that way. Also, does "ccache -s" show the same stats on the different hosts? Regards, Anders
[ccache] sharing a cache
Anders Furuhed wrote: > Hi Enno, > > you get these misses only if different hosts are used? > In that case, have you verified that the same compiler (its size and > modification time) is used on the separate machines? I'm using twoidentical compilers (gcc 2.95.4), both are debian machines, freshly updated. And like I said, the output at least is 100% identical, too. ccache seems to think the input is different, and I'm no closer to figuring out why than I was yesterday. Enno.
[ccache] sharing a cache
Enno Rehling wrote: > we're considering using ccache and sharing the cache between > developers here. I've followed the instructions in the manpage, but > ccache doesn't seem to realize that the object file is already in the > cache, and compiles a new one for every user. > > - The output files have the same md5sum. > - The input files have the same datestamp (I rsynced them) > - I'm compiling from different home directories and machines > > Does any of this play into ccache's decision about whether two > compilations are equal? Apart from the command line, what parameters > go into the hash? > > When both developers use the same machine, they can share the cache. > If they are on separate machines, it seems that they can't. Is there a > way around this? > > Enno. > Hi Enno, you get these misses only if different hosts are used? In that case, have you verified that the same compiler (its size and modification time) is used on the separate machines? It does not matter that the trees are not in the same place unless your code for instance uses #defines to compile the path into the preprocessed output. The timestamp of the source code does not matter at all. Don't give up, ccache and distcc are wonderful :) Regards, Anders Furuhed
[ccache] sharing a cache
we're considering using ccache and sharing the cache between developers here. I've followed the instructions in the manpage, but ccache doesn't seem to realize that the object file is already in the cache, and compiles a new one for every user. - The output files have the same md5sum. - The input files have the same datestamp (I rsynced them) - I'm compiling from different home directories and machines Does any of this play into ccache's decision about whether two compilations are equal? Apart from the command line, what parameters go into the hash? When both developers use the same machine, they can share the cache. If they are on separate machines, it seems that they can't. Is there a way around this? Enno.
[ccache] Re: How to debug ccache
On 28 Mar 2003, Kris Coryn wrote: >From the "HOW IT WORKS" section of the manual: You detect that it is the same code by forming a hash of: * the pre-processor output from running the compiler with -E * the command line options * the real compilers size and modification time * any stderr output generated by the compiler You need to make sure these are the same on both machines. ccache doesn't have any easy way to compare them automatically as far as I know. Basically I suppose you should just work through this list and try to work out what is different. > a simple hello_world.c program works fine, this say that i have configured > the > ccache good. So for hello_world.c you see hits from the second machine as soon as it's compiled? I guess that tells you that at least some of the headers and the compiler are the same. > now i go working but i do a emerge world because it is a gentoo distro to be > sure it al the tools are in sync. Maybe somebody who knows more about Gentoo could help? -- Martin
[ccache] Re: How to debug ccache
> > Sorry, I don't understand what you're trying to say. Sorry for my english but may i try again. the ccache program works perfectly for me. on a machine first compile something it add its work to the cache and the second time a compile the same source it takes the objects from the cache what speed up the compilation time. prima job but now i have other machine and want to have also the speed up in the network setup so if i compile a source on a machine the first time it at his work to the cache that is for every pc the same nfs shared map. ( man ccache SHARING A CACHE is ok) an if i compile the source on a other machine than it takes the object form the network shared cache, but thats my problem a simple hello_world.c program works fine, this say that i have configured the ccache good. but it doesnt work correctly with complexer program's , and like you say al the headers, compilers options, etc etc i dont know all the parameters, must be the same, or there is no hit for it . my question is, how can i let say set a DEBUG_OPTION flag to see all these options and see thats ccache saying there is header.h or gcc-options-x that is not the same like in the ccache files i must recompile this. of course i can make a copie of the disk from my first pc to the second pc this weekend change the ip an go on that must be good, but if i later have installed something newer on the one and not on the other pc than i have the problem again and it should be easy perhaps to backtrace it with toggling a debug option or so in ccache. now i go working but i do a emerge world because it is a gentoo distro to be sure it al the tools are in sync. i hope you understand my problem ? > > Try > > ls -l /usr/bin/gcc > > or whatever compiler name is appropriate. > > Do you have *exactly* the same headers on both machines? If not, you > are likely to get misses. > Kris Coryn
[ccache] Re: How to debug ccache
On 28 Mar 2003, Kris Coryn wrote: > it is not only for the kernel only, it is also for compiling gpm the same > problem, but if i know how to find the different that the ccache program > detect, than i can correct this because it's the same hardware there must not > be a difference at the software. Sorry, I don't understand what you're trying to say. Try ls -l /usr/bin/gcc or whatever compiler name is appropriate. Do you have *exactly* the same headers on both machines? If not, you are likely to get misses. > no, because at the pages http://ccache.samba.org/ there doesnt say there is > one or a link to http://lists.samba.org/cgi-bin/mailman/listinfo/ccache and > because this is a Related projects like you can see there i asked it here, i > hope if andrew Tridgell or his team has some time the correct the pages for > this. Good point. -- Martin
[ccache] Re: How to debug ccache
> On 28 Mar 2003, Kris Coryn wrote: > > first compile a kernel to make the cache files > > a test on the same machine for a second time yes that is ok. > > but when i compile a kernel on a other machine it come not from the cache. > > the second time on the other machine ok but this are the cached files from > > the > > first compile on the other machine, not from the first compilation on the > > first machine of corse > > This is probably because you have slightly different versions of the > compiler installed on each machine, or perhaps different kernel > configuration options. it is not only for the kernel only, it is also for compiling gpm the same problem, but if i know how to find the different that the ccache program detect, than i can correct this because it's the same hardware there must not be a difference at the software. > > You know, you should really ask ccache questions on the ccache list. no, because at the pages http://ccache.samba.org/ there doesnt say there is one or a link to http://lists.samba.org/cgi-bin/mailman/listinfo/ccache and because this is a Related projects like you can see there i asked it here, i hope if andrew Tridgell or his team has some time the correct the pages for this. > > > are there some issue or rtfm that i can use to trace down why this > > compilations are not the same ? > > the machine have the same hardware en software for me, but with parameter > > say > > with the compiling that the compile strings are not te same ? how can i see > > this parameters in a file like the CCACHE_LOGFILE ? > > not just place xxx into cache > > or got cached result for > > but why ? > > -- > Martin > > thanks martin for te reply and i have now also subscribe to te ccache mailing list. kris
[ccache] Re: How to debug ccache
On 28 Mar 2003, Kris Coryn wrote: > first compile a kernel to make the cache files > a test on the same machine for a second time yes that is ok. > but when i compile a kernel on a other machine it come not from the cache. > the second time on the other machine ok but this are the cached files from > the > first compile on the other machine, not from the first compilation on the > first machine of corse This is probably because you have slightly different versions of the compiler installed on each machine, or perhaps different kernel configuration options. You know, you should really ask ccache questions on the ccache list. > are there some issue or rtfm that i can use to trace down why this > compilations are not the same ? > the machine have the same hardware en software for me, but with parameter say > with the compiling that the compile strings are not te same ? how can i see > this parameters in a file like the CCACHE_LOGFILE ? > not just place xxx into cache > or got cached result for > but why ? -- Martin
[ccache] ccache 2.2 and distcc 1.2.2 works
ccache 2.2 and distcc 1.2.2 seem to fix the problem of false misses when these programs are used together. When I build samba's 3_0 branch with CC='ccache distcc gcc-3.2' then almost every file gets a cache hit. -- Martin
[ccache] Intel compiler
> Or perhaps ccache should just cache stdout. distcc sends it across > the network alongside stderr. > > I'm not sure why writing to stdout forces a cache miss. It's because is also very hard to accurately cache both stderr and stdout because of the timing of lines between them. To really accurately cache them ccache would need to record not only what came out of stdout and stderr, but exactly what order the lines came in, so when it is replayed the output looks the same. I'd be happy to add a CCACHE_IGNORE_STDOUT option which would help for the intel compiler. I'm not convinced it is really worth actually cacheing stdout, as the output will probably look pretty strange if we just put all the stdout at the start or end. Cheers, Tridge
[ccache] Intel compiler
On 17 Feb 2003, Anders Furuhed wrote: > I'm considering whether to make a patch for our own use that accepts > a parameterized CCACHE_WHATEVER regexp that is used to filter the > stdout result before deciding not to cache. Or perhaps ccache should just cache stdout. distcc sends it across the network alongside stderr. I'm not sure why writing to stdout forces a cache miss. -- Martin
[ccache] Intel compiler
I was just about to start using ccache with distcc and didn't know the best way to go about, only to discover a just-in-time release that makes it easy! Thanks! Last week we started to use the Intel compiler in parallel with gcc. The Intel compilers produce a number of cool but unnecessary messages about optimizations that take place. Some of these messages can't be turned off and they appear on stdout. The result is that ccache discards the result instead of putting it into the cache. The Intel guys said they would consider introducing an option that turns the remarks off. I'm considering whether to make a patch for our own use that accepts a parameterized CCACHE_WHATEVER regexp that is used to filter the stdout result before deciding not to cache. There's no way we will let something get in the way of us and ccache :). However, it feels like a temporary workaround rather than a nice feature to push for inclusion. If someone has an opinion or wants to have a patch, please mail me (I'm subscribed to the list). Thanks again for today's release! Anders
[ccache] ccache 2.2
I've released ccache 2.2. Changes include: - added a test suite - better integration with distcc - added CCACHE_PREFIX option - disabled hard links by default - recognise some more gcc options (eg. profiling) - added --ccache-skip option Cheers, Tridge
[ccache] ccache shared cache and automake based VPATH builds
Hi, I have ccache 2.1.1 installed and I am trying to use a shared cache. All developers have the following set and appropriate umasks. CCACHE_DIR=/vols/build2/ccache CCACHE_NOLINK=1 Developers never seem to get shared cache hits from other developers, I think because we normally build in a directory not equal to the source dir (usual automake based VPATH build). I've already worked around a problem where there would be a -I to the top source dir (which includes developer name) which would prevent shared caching. Instead I create a symlink to the top sourcedir from the builddir. This allows relative ../.. style paths for the -I that look the same for all developers. Thus "make foo.o" refers to the full path to foo.cpp. As the full path includes the developers username, I think this is may be preventing the ccache from getting a cache hit from a file built by another developer. e.g. automake output from "make foo.o" with my -I workround applied. ccache g++ -DHAVE_CONFIG_H -I. -I../include/source/ate/foo -c -o foo.o `test -f '/home/alex/trees/ate-head/foo/foo.cpp' || echo '/home/alex/trees/ate-head/foo/'`/home/alex/trees/ate-head/foo/foo.cpp Is the path name the problem? If so is there a work around for this? I think I need a ccache based on file basename + file contents rather than file pathname + file contents. I don't think I can do a work around as I did for the includes as the full file path is handed to the compiler by automake. Cheers, Alex.
[ccache] ccache 2.2.1
I released ccache 2.0 a couple of days ago, and have done two minor releases since then to fix small bugs that were noticed in the 2.0 release. Main changes are: - minor Makefile install fixes - fixed some compilation warnings - added -C option for 'clear cache completely' - added CCACHE_CC option - added CCACHE_RECACHE option - added CCACHE_EXTENSION option - added CCACHE_HASHDIR option - embed the hostname in temporary file names for NFS sharing - better handling of the various -M compiler options - handle attempts to compile to stdout - set default max cache size to 1GB - better signal handling Cheers, Tridge
[ccache] -MT / -MP / -MF gcc flags
Hi,
I patched ccache to accept -MT/MP/MF gcc flags (as used by automake v1.7).
It seems to work fine, but do someone really understand what are the
risks with that?
Is it possible that a cached result be returned while it should not?
Thanks.
-jec
Patch I made:
diff -Naur ccache-1.9-orig/ccache.c ccache-1.9-Mflags/ccache.c
--- ccache-1.9-orig/ccache.c2002-05-12 11:55:35.0 +0200
+++ ccache-1.9-Mflags/ccache.c 2002-11-21 14:52:47.0 +0100
@@ -556,6 +556,9 @@
/* cope with -MD, -MM, -MMD before the code below
chucks them */
if (strcmp(argv[i], "-MD") == 0 ||
strcmp(argv[i], "-MM") == 0 ||
+ strcmp(argv[i], "-MT") == 0 ||
+ strcmp(argv[i], "-MP") == 0 ||
+ strcmp(argv[i], "-MF") == 0 ||
strcmp(argv[i], "-MMD") == 0) {
args_add(stripped_args, argv[i]);
continue;
--
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 9, 1020 Renens Switzerland
Tel +41 21 632 9043 Fax +41 21 632 9090
E-mail: jean-eric.cuen...@linkvest.com
http://www.linkvest.com
[ccache] -MT / -MD flags
Hi, I patched ccache to accept -MT (as used by automake v1.7). It seems to work fine, but do yomeone really understand what are the risks with that? Is it possible that a cached result be got while it shuld not be? Thanks -jec -- Jean-Eric Cuendet Linkvest SA Av des Baumettes 9, 1020 Renens Switzerland Tel +41 21 632 9043 Fax +41 21 632 9090 E-mail: jean-eric.cuen...@linkvest.com http://www.linkvest.com
[ccache] ccache+distcc.patch+distcc-0.14 = segmentation fault
I cannot remember who (sorry) submitted the attached patch to allow ccach to automatically use distcc by setting the env variable CCACHE_DISTCC=1. This worked great with ccache-1.9 and distcc-0.12. Just upgraded to distcc-0.14 and this patch causes segmentation faults. I double checked, by remove the patch and recompiling ccache and everything works. Any help would be appreciated. Thanks. -- Bob Tanner| Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 -- next part -- A non-text attachment was scrubbed... Name: ccache-1.9-distcc.patch Type: text/x-diff Size: 2839 bytes Desc: not available Url : http://lists.samba.org/archive/ccache/attachments/20021120/2bbe11cf/ccache-1.9-distcc.bin
[ccache] Re: disk full and distcc/ccache weirdness
On 23 Sep 2002, Tim Potter wrote: > Hi Tridge. I've just had some distcc/ccache wierdness that caused my > ccache to be corrupted. One of the machines in our DISTCC_HOSTS list > filled up /tmp and a whole bunch of object files were created containing > text like: > > DOMAIN_GRP:t(239,22)=(239,21) > domain_grp_member_info:T(239,23)=s257name:(211,2),0,2048;attr:(0,11),2048,8;; > DOMAIN_GRP_MEMBER:t(239,24)=(239,23) > time_info:T(239,25)=s4time:(0,4),0,32;; > The exact error returned was: > > Linking bin/smbd > lib/fsusage.o: file not recognized: File truncated > > I haven't been able to reproduce it by filling up /tmp again and > rebuilding so I'm not sure what sort of bug it is. )-: The bug is that execute() in execute.c only checks WEXITSTATUS(), not WIFSIGNALLED(). If the compiler exits with a signal ccache will proceed as if it succeeded, and therefore probably corrupt its cache. Old versions of distcc would raise SIGABRT if something strange like ENOSPC when writing a file happened. (New ones are practically perfect in every possible way. :-) -- Martin
[ccache] GNU ar 2.9-gnupro-99r1p1 crashed when using with ccache.
On 7 Nov 2003, "Chum, Andrew H." wrote: > I am trying to use ccache 2.3 and I used 1.9 before. Nothing works for > me now. The ar crashed on me with both 1.9 and 2.3 version of ccache. > Did anyone experience that? If my ar is too old, which version of ar > should I use? I don't know of anyone else seeing this. You might like to take it up with the ar maintainers. -- Martin linux.conf.au -- Adelaide, January 2004
[ccache] CCACHE_PREFIX included in hash
On 31 Oct 2003, Brian Poynor wrote: > Is CCACHE_PREFIX intentionally included in the hash? Yes. > For my project it means that objects built locally never match objects > built remotely with CCACHE_PREFIX=distcc, even though they are > identical, and I'd like to avoid duplicate cache entries. > > If interested, I have a patch which avoids hashing it. Currently it is > implemented as an alternate environment variable, CCACHE_NHPREFIX. Please post it. -- Martin linux.conf.au -- Adelaide, January 2004
