Re: [ccache] ccache version 3.2.3 has been released
Mike Frysinger vap...@gentoo.org writes: On 16 Aug 2015 13:39, Tom Lane wrote: and of course -lz isn't a valid dependency. that's not really true. make will expand it internally into paths like /usr/lib/libz.so. Hmm ... there may be versions of make for which that's true, but Apple's version (which is gnu make 3.81) does not like it. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache version 3.2.3 has been released
Joel Rosdahl j...@rosdahl.net writes: I'm happy to announce ccache version 3.2.3. Hate to be the bearer of bad news, but this fails to build for me on late-model OS X: $ ./configure $ make gcc -DHAVE_CONFIG_H -DSYSCONFDIR=/usr/local/etc -I. -I. -g -O2 -Wall -W -c -o main.o main.c ... gcc -DHAVE_CONFIG_H -DSYSCONFDIR=/usr/local/etc -I. -I. -g -O2 -Wall -W -c -o conf.o conf.c make: *** No rule to make target `-lz', needed by `ccache'. Stop. The reason appears to be that the Makefile gets generated like so: $ grep extra_libs Makefile extra_libs = -lz ccache$(EXEEXT): $(ccache_objs) $(extra_libs) $(CC) $(all_cflags) -o $@ $(ccache_objs) $(all_ldflags) $(extra_libs) $(LIBS) test/main$(EXEEXT): $(base_objs) $(test_objs) $(extra_libs) $(CC) $(all_cflags) -o $@ $(base_objs) $(test_objs) $(all_ldflags) $(extra_libs) $(LIBS) and of course -lz isn't a valid dependency. Manually removing $(extra_libs) from these two dependency lists fixes it. I do not recall having had this problem the last time I built ccache, but that was 3.2.1, so I don't know whether it was introduced in 3.2.2 or 3.2.3. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache interrupt handling bug
Nadav Har'El n...@cloudius-systems.com writes: First of all, thanks. This indeed fixes the bug, and is exactly the first patch I tried to fix it this problem. I want to explain, though, why I ended up sending a different patch for this problem - a 4-line patch instead of this one-liner. The explanation is not very important, and I should probably have done this earlier, but perhaps someone would find it interesting. When the user types ^C, the operating system sends SIGINT to all processes belonging to the terminal's process group - and in particular it sends SIGINT to *both* the child compiler and ccache, separately. Your patch makes ccache exit as soon as it gets the SIGINT - but the child compiler might still be running for a while longer. This will usually be fine, but I thought the user can be surprised if he sees ccache (which he considers to be the compiler) exit, but ps shows the compiler is still running. This would be especially annoying if some hypothetical compiler trapped SIGINT deliberately, and continued to run long after ccache exits. Actually, that's a bug not just a cosmetic problem, because it introduces a race condition. Consider this sequence of events: * make launches ccache gcc -o test.o test.c * user types control-C * ccache receives SIGINT and exits * make does unlink(test.o) to clean up after failed compile step, which it thinks is done * gcc creates test.o * gcc receives SIGINT and exits We're left with a probably-broken test.o in the filesystem, despite make's attempt to clean up. Now, the window for this is pretty narrow, but I think it could happen: I don't believe that sending signals to multiple processes is atomic in most kernels. You really don't want ccache to exit until after all externally-observable things have stopped happening. (I recently fixed a somewhat related bug in Postgres :-(, which is why this caught my eye.) regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache interrupt handling bug
Nadav Har'El n...@cloudius-systems.com writes: On Mon, Aug 17, 2015 at 12:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: * make launches ccache gcc -o test.o test.c * user types control-C * ccache receives SIGINT and exits * make does unlink(test.o) to clean up after failed compile step, which it thinks is done * gcc creates test.o Stupid question: Does ccache let gcc write to test.o directly, or does it write to some temporary file and then ccache copies it? Dunno, but that just moves the problem somewhere else no? For instance, in the code fragment you mentioned, I wonder whether it's sane to do clean_up_pending_tmp_files(); when gcc is still on the loose. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
[ccache] Compiler warnings in ccache 3.2.3
I got a few warnings about assignments of pointers to bool values.
I think these are legitimate gripes, because on platforms where bool
is only a byte wide, the net effect will be to assign the pointer's
low-order byte to the bool. There's at least a 1-in-256 chance of
a non-null pointer erroneously converting to a false boolean value
(maybe more than that, if the pointer is likely to be aligned ...).
I propose the attached patches to fix this.
regards, tom lane
diff -c -r orig/ccache-3.2.3/ccache.c ccache-3.2.3/ccache.c
*** orig/ccache-3.2.3/ccache.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/ccache.c Sun Aug 16 14:59:46 2015
***
*** 1263,1269
compiler_is_clang(struct args *args)
{
char *name = basename(args-argv[0]);
! bool is = strstr(name, clang);
free(name);
return is;
}
--- 1263,1269
compiler_is_clang(struct args *args)
{
char *name = basename(args-argv[0]);
! bool is = strstr(name, clang) != NULL;
free(name);
return is;
}
diff -c -r orig/ccache-3.2.3/conf.c ccache-3.2.3/conf.c
*** orig/ccache-3.2.3/conf.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/conf.c Sun Aug 16 15:01:12 2015
***
*** 58,64
char **value = (char **)result;
free(*value);
*value = subst_env_in_string(str, errmsg);
! return *value;
}
static bool
--- 58,64
char **value = (char **)result;
free(*value);
*value = subst_env_in_string(str, errmsg);
! return *value != NULL;
}
static bool
diff -c -r orig/ccache-3.2.3/language.c ccache-3.2.3/language.c
*** orig/ccache-3.2.3/language.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/language.c Sun Aug 16 15:01:01 2015
***
*** 149,155
bool
language_is_supported(const char *language)
{
! return p_language_for_language(language);
}
bool
--- 149,155
bool
language_is_supported(const char *language)
{
! return p_language_for_language(language) != NULL;
}
bool
diff -c -r orig/ccache-3.2.3/util.c ccache-3.2.3/util.c
*** orig/ccache-3.2.3/util.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/util.c Sun Aug 16 15:00:41 2015
***
*** 1638,1644
if (curly) {
if (*q != '}') {
*errmsg = format(syntax error: missing '}' after \%s\, p);
! return NULL;
}
}
--- 1638,1644
if (curly) {
if (*q != '}') {
*errmsg = format(syntax error: missing '}' after \%s\, p);
! return false;
}
}
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] MacOSX: cache losing clang/llvm debug symbols with separate compilation…
Christophe de Dinechin christophe.de.dinec...@gmail.com writes: Apparently, ccache loses debug symbols on Mavericks with clang/lldb. Here is a session illustrating the problem. I spent quite a bit of time figuring out that ccache was the culprit, so I thought I'd share also on the clang and LLVM mailing lists in case someone else runs into this. FWIW, ccache and lldb seem to play together nicely for me, so I guess there's some other contributing factor in your case. I'm using: OSX 10.9.4 lldb 310.2.37 (from Xcode 5.1.1) self-compiled ccache 3.1.9 regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
