Hi, > I tried to install ccache 3.1.9 on a current Mac system (OS X 10.9.3, > Xcode 5.1.1). Configure and compile went cleanly, with the exception > of two probably-harmless warnings: [...]
Thanks for the patch. The build warning has however already been fixed in another way in ccache (not released yet, though). You can get hold of the latest development source code here: http://ccache.samba.org/repo.html > I did some further experiments and concluded that ccache is in fact kind > of broken: when I try to compile a large project with it, I get thousands > of weird warnings that do not appear when using gcc directly (many of them > the same kind of "unused -I argument" bleat shown above, but others are > warnings about C constructs that I don't normally see any warnings about). As mentioned in the ccache manual: "Only works with GCC and compilers that behave similar enough". You are not using GCC but clang, which does not behave similar enough... As a workaround, you can set CCACHE_CPP2, as mentioned by Lubos Lunak. In the yet unreleased ccache 3.2 version, that shouldn't be necessary. > In any case, surely it's unexpected that ccache would change > the compiler's warning behavior? It's expected if the compiler emits different warnings when compiling from source code compared with compiling from preprocessed source code since that's how ccache operates. -- Joel On 31 May 2014 20:24, Tom Lane <t...@sss.pgh.pa.us> wrote: > I tried to install ccache 3.1.9 on a current Mac system (OS X 10.9.3, > Xcode 5.1.1). Configure and compile went cleanly, with the exception > of two probably-harmless warnings: > > manifest.c:223:2: warning: shift count >= width of type > [-Wshift-count-overflow] > READ_INT(1, version); > ^~~~~~~~~~~~~~~~~~~~ > manifest.c:150:10: note: expanded from macro 'READ_INT' > (var) <<= 8; \ > ^ ~ > manifest.c:230:2: warning: shift count >= width of type > [-Wshift-count-overflow] > READ_INT(1, mf->hash_size); > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > manifest.c:150:10: note: expanded from macro 'READ_INT' > (var) <<= 8; \ > ^ ~ > 2 warnings generated. > > I made this change to silence that, since I think that the C standard > allows compilers to consider the case undefined behavior: > > $ diff -c manifest.c~ manifest.c > *** manifest.c~ Sun Jan 6 11:57:59 2013 > --- manifest.c Sat May 31 13:42:53 2014 > *************** > *** 147,154 **** > if (ch_ == EOF) { \ > goto error; \ > } \ > ! (var) <<= 8; \ > ! (var) |= ch_ & 0xFF; \ > } \ > } while (0) > > --- 147,153 ---- > if (ch_ == EOF) { \ > goto error; \ > } \ > ! (var) = (((unsigned int) (var)) << 8) | (ch_ & > 0xFF); \ > } \ > } while (0) > > but it's probably not really an issue. However, "make test" refuses > to do anything much: > > ... > PASSED: 178 assertions, 64 tests, 9 suites > CC='gcc' ./test.sh > WARNING: Compiler gcc not supported (version: Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1) > -- not running tests > > I looked at test.sh and concluded that it simply didn't recognize the > output of "gcc --version", which looks like this: > > $ gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 > Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) > Target: x86_64-apple-darwin13.2.0 > Thread model: posix > > So I diked out that check from the test script and tried again. > The first half dozen test suites went OK, but in the "basedir" > testsuite I got a lot of chatter: > > clang: warning: argument unused during compilation: '-I > /Users/tgl/src/ccache-3.1.9/testdir.20963/dir1/include' > clang: warning: argument unused during compilation: '-I > /Users/tgl/src/ccache-3.1.9/testdir.20963/dir2/include' > clang: warning: argument unused during compilation: '-I include' > clang: warning: argument unused during compilation: '-I include' > clang: warning: argument unused during compilation: '-I include' > [ much more in the same vein... ] > > and then the "pch" testsuite failed altogether: > > starting testsuite pch > SUITE: "pch", TEST: "no -fpch-preprocess, -include" - Expected "cache > miss" to be 1, got 0 > cache directory > /Users/tgl/src/ccache-3.1.9/testdir.20963/.ccache > cache hit (direct) 0 > cache hit (preprocessed) 0 > cache miss 0 > preprocessor error 1 > files in cache 0 > cache size 0 Kbytes > max cache size 1.0 Gbytes > TEST FAILED > Test data and log file have been left in testdir.20963 > make: *** [test] Error 1 > > I did some further experiments and concluded that ccache is in fact kind > of broken: when I try to compile a large project with it, I get thousands > of weird warnings that do not appear when using gcc directly (many of them > the same kind of "unused -I argument" bleat shown above, but others are > warnings about C constructs that I don't normally see any warnings about). > The resulting executables seem to work, but I can't use a toolchain that's > this noisy. In any case, surely it's unexpected that ccache would change > the compiler's warning behavior? > > I don't know enough about ccache to debug this, but will be happy > to supply further info if given directions how to get it. > > (BTW, I successfully installed the same ccache source code on two > older Apple systems, and it's working as expected there.) > > regards, tom lane > _______________________________________________ > ccache mailing list > ccache@lists.samba.org > https://lists.samba.org/mailman/listinfo/ccache > _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
