ccache – a fast compiler cache
Home Page: https://ccache.dev
License: Other
Ccache is a compiler cache. It speeds up recompilation by caching previous compilations and detecting when the same compilation is being done again.
If basedir is used and the source file path is absolute and is a symlink, then #included files will be taken from the wrong directory.
How to reproduce:
#!/bin/sh
tmpdir=$(mktemp -d)
trap "cd /; rm -rf $tmpdir" EXIT
cd $tmpdir
export CCACHE_DIR=ccache
export CCACHE_BASEDIR=/
gcc=/usr/bin/gcc
ccache=ccache
mkdir d
echo '#define A "BUG"' >d/h.h
cat <<EOF >d/c.c
#include <stdio.h>
#include "h.h"
int main() { printf("%s\n", A); }
EOF
echo '#define A "OK"' >h.h
ln -s d/c.c c.c
echo -n "Without ccache: "
$gcc -c $PWD/c.c
$gcc c.o -o c
./c
echo -n "With ccache: "
$ccache $gcc -c $PWD/c.c
$gcc c.o -o c
./c
Introduced in 2df269a, so exists in ccache 3.1.8 and newer.
See also Debian bug #829088.
I am trying to compile ccache 3.3.3 on Solaris 10 with Oracle Studio 12 and get a compilation error.
The required flags for C99 are detected as follows:
checking for /opt/SUNWspro/bin/cc option to accept ISO C89... none needed
checking for /opt/SUNWspro/bin/cc option to accept ISO C99... -D_STDC_C99=
checking how to run the C preprocessor... /opt/SUNWspro/bin/cc -D_STDC_C99= -E
which results in a compilation error with inconsistently set preprocessor flags:
/opt/SUNWspro/bin/cc -D_STDC_C99= -DHAVE_CONFIG_H -DSYSCONFDIR=/etc/opt/csw -I. -I. -I/opt/csw/include -I./zlib -xO3 -m32 -xarch=sparc -O -c -o args.o args.c
"/usr/include/sys/feature_tests.h", line 337: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
The addition of -D_XPG6 to CPPFLAGS solves the issue.
Even though -coverage is specified, ccache fails to handle the .gcda file.
rm url_handler_test*
make
results in url_handler_test.o and url_handler_test.d , but no url_handler_test.gcda
g++-610-compat is just a shell script which runs
exec /usr/local/bin/g++-610 -D_GLIBCXX_USE_CXX11_ABI=0
In file included from conf.c:200:
confitems.gperf:33:35: error: static function 'parse_bool' is used in an inline function with external linkage [-Werror,-Wstatic-in-inline]
{"stats", 23, ITEM(stats, bool)},
^
conf.c:196:2: note: expanded from macro 'ITEM'
parse_##type, offsetof(struct conf, name), NULL
^
:72:1: note: expanded from here
parse_bool
^
confitems.gperf:54:1: note: use 'static' to give inline function 'confitems_get' internal linkage
__inline
^
static
conf.c:39:1: note: 'parse_bool' declared here
parse_bool(const char _str, void *result, char *_errmsg)
...
and for all the static functions used to define the ITEM and ITEM_V macros
or simply remove the static form the function.
This line looks quite suspicious to me:
https://github.com/jrosdahl/ccache/blob/25da80c2935646f22461d37fb1a768e742467ce3/ccache.c#L807
Shouldn't it be something like this?
ret = copy_file(source, dest,
conf->compression ? conf->compression_level : 0);When I run the following lines with ccache 3.3, I get the same armv7 binary two times instead of one for armv7 and one for arm64 with ccache 3.2.7. The same happens when building for simulator using two lines for i386 and x86_64.
It is great that ccache 3.3 is now supporting to build with multiple -arch flags in one line but old builds should not break.
run one time with ${target} = armv7 and one time with ${target} = arm64:
ccache $(xcrun -sdk iphoneos -find clang) -x c++ -std=c++14 -O2 -arch ${target} -isysroot $PLATFORMPATH/$platform.platform/Developer/SDKs/$platform$SDKVERSION.sdk -miphoneos-version-min=$IPHONEOS_DEPLOYMENT_TARGET
The stats files need to have the same umask as other files, when sharing the cache among users.
It is now created as a tmp file and renamed, without updating the file permission.
I'm not sure what the most proper fix is so reporting as an issue here instead of / before suggesting a patch.
I guess this commit is to blame:
commit fc61ca9
Author: Joel Rosdahl [email protected]
Date: Sat Nov 15 13:16:40 2014 +0100
Improve temporary file creation functions and usage
This is with ccache 3.2.6 on Fedora 24 and development, gcc 6.1.1:
CC='gcc' ./test.sh
compiler: /usr/lib64/ccache/gcc
version: gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test dir: testdir.8818
starting testsuite base
SUITE: "base", TEST: "-D not hashed" - Expected "cache hit (preprocessed)" to be 14, got 13
cache directory /builddir/build/BUILD/ccache-3.2.6/testdir.8818/.ccache
primary config /builddir/build/BUILD/ccache-3.2.6/testdir.8818/.ccache/ccache.conf
secondary config (readonly) /etc/ccache.conf
cache hit (direct) 0
cache hit (preprocessed) 13
cache miss 40
called for link 2
called for preprocessing 2
multiple source files 1
compiler produced stdout 1
couldn't find the compiler 1
bad compiler arguments 1
unsupported source language 2
unsupported compiler option 1
output to a non-regular file 1
no input file 1
files in cache 3
cache size 12.3 kB
max cache size 5.0 GB
TEST FAILED
Test data and log file have been left in testdir.8818
Makefile:103: recipe for target 'test' failed
I compiled the attached ccache.c using the commands in ccache_build.txt. As seen in that file, I get the expected error when building using gcc directly, but not when building via ccache. I would expect to get the error also when building via ccache.
ccache used is 3.2.4.
gcc used is 6.1.1.
system is Fedora 24.
(I had to rename ccache.c to ccache.txt because github didn't like the file type ...)
gcc's -fstack-usage flag will output a .su file alongside the object. when using ccache, that file is lost :(.
in the example below, note that there is no test.su file when using ccache:
$ echo 'int main(){return 0;}' > test.c
$ /usr/bin/gcc test.c -fstack-usage -c
$ ls test.*
test.c test.o test.su
$ rm test.o test.su
$ ccache gcc test.c -fstack-usage -c
$ ls test.*
test.c test.o
The resulting dependency file is not always correct when specifying the -MD or -MMD options to the compiler.
example:
$ # Make two identical source directories
$ mkdir a
$ touch a/source.c
$ rsync -a a/ b
$
$ # Cache entry added for directory "a"
$ ccache /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: a/source.c
$
$ # Cache entry added for directory "b"
$ ccache /usr/bin/cc -MMD -c b/source.c && cat source.d
source.o: b/source.c
$
$ # Incorrect cached results used for directory "a"
$ ccache /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: b/source.c
$
$ # Verify compiler gives different results
$ /usr/bin/cc -MMD -c a/source.c && cat source.d
source.o: a/source.c
The Ninja generator of CMake uses the -MMD compiler option to cache dependencies. This means that anyone using Ninja with a CMake project will encounter this bug if the source code is moved.
I hope I will be able to make sense in this bug report because there is a lot of things I don't quite understand myself.
We have OSX build machines with 8 physical cores, or 16 logical cores, and we see a 25% reduction in fully cached build speed if we try to use 16 build threads (7 minutes instead of 5 minutes). Reducing the number of threads to 8 seems to make cached builds fast again, but that will obviously hurt non-cached builds badly.
We noticed this already last year but didn't really debug very deeply. The only thing I can find from back then is "in the slow builds with ccache, effectively all time was spent in open() trying to acquire a file system lock".
From https://bugzilla.samba.org/show_bug.cgi?id=11712:
The current documentation says this:
unify (CCACHE_UNIFY) [boolean]
... Also note that enabling the unifier implies turning off the direct mode.
It seems like these could be used together. For instance, if the direct hash lookup misses, run the preprocessor and unifier, and lookup that hash.
Alternatively, if ccache already behaves this way, please update the documentation.
When trying to build kernel a 2nd time I get this error:
If I use CCACHE_RECACHE=1 it works, but nothing is cached.
ccache version: 3.3.1
cat: /home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/objtool/.fixdep.o.d: No such file or directory
/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/build/Makefile.build:77: recipe for target '/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/objtool/fixdep.o' failed
make[6]: *** [/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/objtool/fixdep.o] Error 1
Makefile:36: recipe for target '/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/objtool/fixdep-in.o' failed
make[5]: *** [/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/objtool/fixdep-in.o] Error 2
/home/spstarr/rpmbuild/BUILD/kernel-4.8.0_rc7+/tools/build/Makefile.include:7: recipe for target 'fixdep' failed
make[4]: *** [fixdep] Error 2
Makefile:60: recipe for target 'objtool' failed
make[3]: *** [objtool] Error 2
Makefile:1594: recipe for target 'tools/objtool' failed
make[2]: *** [tools/objtool] Error 2
make[2]: *** Waiting for unfinished jobs....
error: Bad exit status from /var/tmp/rpm-tmp.XJXuNg (%build)
The -ccbin argument specifies the path to the host compiler or the directory in which it resides. Currently, ccache treats the argument as a source file and bails out with "unsupported language."
With ccache 3.3.x it happens that the linux kernel image is the same after changing the source code and rebuilding it. On some machine I can reproduce this always on some other not. Dunno why.
I already mentioned the issue in #133 and #134 because I assumed there is some relation but now I found out the reason:
What's happening is that arch/x86/boot/compressed/piggy.o is taken from cache even that the arch/x86/boot/compressed/piggy.S files dependencies changed. The file piggy.S includes another file via .incbin directive. In the manual I read in the sectiion "CAVEATS" that this directive is not correcty handled by ccache so its actually documented. You cannot expect that all users of ccache find out and workaround this issue by themself. So that should be fixed because this .incbin seems to be used by at least one large project.
Edited: Initially I mentioned ccache 3.2.x but meant 3.3.x. Sorry.
Hi. Would be nice to see in ccache -s output one more line:
cache hit % 49.21%
calculated as (hitDirect + hitPreprocessed) * 100 / (hitDirect + hitPreprocessed + miss), without taking into account non-cachable calls (like called for link/preprocess/etc.).
"Clang and GCC (starting with 4.9) support color output if possible, but since ccache redirects stderr to a file, they detect the output is not a terminal and do not enable colors"
A patch has been around on your mailing list for over 6 months, could you add this in?
Here's the latest version I can find:
https://www.mail-archive.com/[email protected]/msg01092.html
All credit to Lubos Lunak for the patch - I just thought it might get more attention or feedback from other users here than it has done on the mailing list.
With clang, unless -fno-split-dwarf-inlining is used (on trunk, it isn't supported on current 3.9.0), the order between -g* and -gsplit-dwarf matters, see https://github.com/llvm-mirror/clang/blob/master/lib/Driver/Tools.cpp#L4776.
But ccache doesn't preserve the order :
Command line: clang++ -g1 -gsplit-dwarf -c -o test.o test.cpp
...
Executing /usr/bin/clang++ -gsplit-dwarf -g1 -fcolor-diagnostics -E test.cpp
...
Running real compiler
Executing /usr/bin/clang++ -gsplit-dwarf -g1 -fcolor-diagnostics -c -o test.o test.cpp
Compiler didn't produce a split dwarf file
Failed; falling back to running the real compiler
Executing /usr/bin/clang++ -g1 -gsplit-dwarf -c -o test.o test.cpp
In this case, "-g1 -gsplit-dwarf" (same as "-gsplit-dwarf") becomes "-gsplit-dwarf -g1" (same as "-g1"), which doesn't write a dwo.
So when starting from a clean build tree with a clean cache, ccache runs the compiler again with the original arguments like in the traces above.
But later, if the dwo already exists :
If the user looks at the file dates at this point, he can see the issue (the .dwo is older than the .o).
But after cleaning the build tree, it becomes really confusing, since on the next build ccache restores the cached .o and .dwo, so :
Could ccache do something here ?
If the order was preserved, this specific case would work, but "-gsplit-dwarf -g1" would always fail, re-run the compiler, and nothing would be cached (since clang wouldn't create the dwo).
Perhaps the only solution would be to launch clang with "-###", then parse the cc1 arguments, since the driver handles the conflicting or overlapping options before calling the frontend. But it would be a massive change, and would require clang-specific code, since the cc1 options are different (and could change between versions...).
There might be some items in my paths that'd affect this, but I thought I'd report it anyway.
Let me know if you need more info.
Configure line:
CC=gcc-mp-4.9 ./configure
gmake check output:
test/test_argument_processing.c:93: Failed assertion:
Suite: argument_processing
Test: preprocessor_only_flags_should_only_be_sent_to_the_preprocessor
Expression: act_cc
Expected: cc -c
Actual: cc -I. -idirafter . -iframework. -imacros . -imultilib . -include test.h -include-pch test.pch -iprefix . -iquote . -isysroot . -isystem . -iwithprefix . -iwithprefixbefore . -DTEST_MACRO -DTEST_MACRO2=1 -F. -trigraphs -fworking-directory -fno-working-directory -c
FAILED: 1 test
Makefile:83: recipe for target 'test' failed
gmake: *** [test] Error 1
Hi,
In the stats there is a line "compiler produced stdout"
I can find no explanation in the documentation or elsewhere of what it means exactly and what should be done to avoid this.
thanks!
James
[2016-11-08T11:16:28.688683 19644] Manifest file has bad magic number 1013343290
[2016-11-08T11:16:28.688692 19644] Corrupt manifest file
[2016-11-08T11:16:28.688696 19644] Failed to read manifest file; deleting it
Steps to reproduce:
sudo xcode-select -s /Applications/Xcode8.app/Contents/Developer
./autogen.sh
./configure
make
CC=clang ./test
# Test suite: multi_arch
# Test case: cache hit, direct mode
# Failure reason: Expected "cache hit (direct)" to be 1, actual 0
However, everything works if ccache is compiled with clang from Xcode 7.3.1:
sudo xcode-select -s /Applications/Xcode7.3.1.app/Contents/Developer
./autogen.sh
./configure
make
CC=clang ./test
I have some curious behaviour here in a c++ project. I generate MSVC project files, then run cmake once more and a pre-processor define (DEBUG) is duplicated in the CMakeCache.txt file in the External Cache Entries CMAKE_CXX_FLAGS_DEBUG section and also appended to the list in the <PreprocessorDefinitiion> tag in ".vcxproj"
Run cmake again without changing the CMake files and another copy is appended.
First generation...
CMakeCache.txt
//Debug CXXFLAGS
CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -DDEBUG
.vcxproj
<PreprocessorDefinitions>WIN32;_WINDOWS;_DEBUG;DEBUG......;CMAKE_INTDIR=\"Debug\";%(PreprocessorDefinitions)</PreprocessorDefinitions>
Second generation..
//Debug CXXFLAGS
CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -DDEBUG -DDEBUG
<PreprocessorDefinitions>WIN32;_WINDOWS;_DEBUG;DEBUG;DEBUG......;CMAKE_INTDIR=\"Debug\";%(PreprocessorDefinitions)</PreprocessorDefinitions>
Unfortunately I can't share the CMakeLists.txt files with you but hoped that maybe someone was aware of this issue or if it's a common user mistake I've made somewhere?
Of course this causes MSVC to rebuild the entire project even if that shouldn't be necessary.
Any ideas? Can try and produce a standalone example if nobody has any ideas.
Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1373295
Reproducer:
First install VirtualBox's build dependencies. I guess this could be trimmed down to some extent, but for example for current Fedora x86_64 development this would be taken care of by:
dnf install iasl kBuild SDL-devel xalan-c-devel openssl-devel libcurl-devel libxslt-devel xerces-c-devel libIDL-devel yasm pulseaudio-libs-devel python2-devel desktop-file-utils libcap-devel qt5-qtbase-devel qt5-qtx11extras-devel qt5-linguist pam-devel mkisofs java-devel boost-devel libxml2-devel libpng-devel zlib-devel device-mapper-devel libvpx-devel makeself libdrm-devel libpciaccess-devel mesa-libGL-devel mesa-libOSMesa-devel mesa-libEGL-devel pixman-devel xorg-x11-proto-devel xorg-x11-server-devel libXcursor-devel libXcomposite-devel libXmu-devel libXinerama-devel "libstdc++-static(x86-64)" "libstdc++-static(x86-32)" "glibc(x86-32)" "glibc-devel(x86-32)" "libgcc(x86-32)"
Then proceed with getting and building:
$ curl -O http://download.virtualbox.org/virtualbox/5.1.4/VirtualBox-5.1.4.tar.bz2
$ tar xf VirtualBox-5.1.4.tar.bz2
$ cd VirtualBox-5.1.4
$ sed -i -e 's/\(\$cc_maj -eq 6 -a \$cc_min -gt\) 1/\1 2/' configure # if gcc is >= 6.2
$ ./configure --disable-kmods --disable-docs --with-gcc="ccache gcc" --with-g++="ccache g++"
$ source ./env.sh
$ kmk KBUILD_VERBOSE=2
Results in bunch of errors like:
cc1: error: to generate dependencies you must specify either -M or -MM
cc1plus: error: to generate dependencies you must specify either -M or -MM
This is at least with current Fedora development, gcc 6.2.1, ccache 3.3 (and 3.2.7 with CCACHE_CPP2 turned on). Turning off CCACHE_CPP2 avoids the errors.
Letting hash_dir default to true will result in a better out-of-the-box experience.
See also the discussion in #93.
I have to build some projects under cygwin now and then, with toolchain from here : https://launchpad.net/gcc-arm-embedded
The peculiarity of these toolchain builds for windows is that they accept relative paths just fine, and everything passed in in 'cygpath mixed format' , i.e e:/dir/file.c, but absolute cygwin paths like /cygdrive/e/dir/file.c are not recognized.
ccache currently passes in preprocessed files as absolute pathnames, and obviously this will fail, the toolchain will not find the file.
I wrote a quick horrible hack ( which i'm not proud of, but i needed to get this working ) to run 'cygpath -m' on the input filenames, which currently works for me for this particular project:
kaidokert@24a2ba8
This would fail in more complex situations as there are are i think other places in ccache code where it would pass in absolute paths to temporary files ( precompiled headers maybe ? )
Is it worth doing this properly via a config parameter, or is this just too messy/broken config to deal with ? The hack is fine for me and saves me hours of compile time
I can't test speed for MD4 but as i think,
https://code.google.com/p/xxhash/
md4 not much faster then md5
I will try to port ccache for using xxhash instead of md4 like this
markfasheh/duperemove#33
[$] fallocate -l 1G /tmp/test
[$] time md4sum /tmp/test
ca2bc5d1f9b9325b6ea9547104ac26ca
md4sum /tmp/test 1.06s user 0.06s system 100% cpu 1.117 total
[$] time md5sum /tmp/test
cd573cfaace07e7949bc0c46028904ff /tmp/test
md5sum /tmp/test 1.74s user 0.06s system 99% cpu 1.808 total
[$] time ./xxh32sum /tmp/test
31ec1cce /tmp/test
./xxh32sum /tmp/test 0.19s user 0.06s system 100% cpu 0.249 total
[$] time ./xxh64sum /tmp/test
cf9ad580b7ff077f /tmp/test
./xxh64sum /tmp/test 0.11s user 0.06s system 99% cpu 0.170 total
We are sharing the ccache dir on an NFS share. During high load, we are seeing consistent "Stale NFS file handle" errors to the stats file.
Any suggestions as to what can be done to avoid this problem?
[2016-02-10T14:16:20.237532 12551] Trying direct lookup
[2016-02-10T14:16:20.238577 12551] Looking for object file hash in /nfs/compile_cache/a/5/c2da3efd19dcc3ef79042ca6df7c02-26442.manifest
[2016-02-10T14:16:20.706020 12551] Got object file hash from manifest
[2016-02-10T14:16:20.711564 12551] Copying /nfs/compile_cache/1/c/87c3236c570c5e35767209c40fcdc7-7031461.o to /out_dir/BubbleInsertionTest.obj via /out_dir/BubbleInsertionTest.obj.fmyciw202.12551.Jq5p9b (uncompressed)
[2016-02-10T14:16:20.724023 12551] Created from cache: /nfs/compile_cache/1/c/87c3236c570c5e35767209c40fcdc7-7031461.o -> /out_dir/BubbleInsertionTest.obj
[2016-02-10T14:16:20.726563 12551] Copying /nfs/compile_cache/1/c/87c3236c570c5e35767209c40fcdc7-7031461.d to /out_dir/BubbleInsertionTest.d via /out_dir/BubbleInsertionTest.d.fmyciw202.12551.kcTxOq (uncompressed)
[2016-02-10T14:16:20.734324 12551] Created from cache: /nfs/compile_cache/1/c/87c3236c570c5e35767209c40fcdc7-7031461.d -> /out_dir/BubbleInsertionTest.d
[2016-02-10T14:16:20.737888 12551] Succeeded getting cached result
[2016-02-10T14:16:20.738724 12551] Acquired lock /nfs/compile_cache/1/stats.lock
[2016-02-10T14:16:20.750046 12551] Releasing lock /nfs/compile_cache/1/stats.lock
[2016-02-10T14:16:20.750053 12551] Unlink /nfs/compile_cache/1/stats.lock
[2016-02-10T14:16:20.751956 12551] Result: cache hit (direct)
[2016-02-10T14:16:20.751964 12551] Cleaning up cache directory /nfs/compile_cache/1
******[2016-02-10T14:16:56.050417 12551] FATAL: lstat /nfs/compile_cache/1/stats failed: Stale NFS file handle*****
If I have a C++11 file containing a raw string such as:
const char* foo = R"(
something
http://google.com
)";Then the // in the URL gets interpreted as a comment and any changes to the URL inside the raw string are counted as equivalent sources.
To repro:
echo 'int main() { return 0; }' > a.c
CCACHE_LOGFILE=ccache.log ccache gcc -MMD -MF a-1.dep -c a.c -o a.o
CCACHE_LOGFILE=ccache.log ccache gcc -MMD -MF a-1.dep -c a.c -o a.o
CCACHE_LOGFILE=ccache.log ccache gcc -MMD -MF a-2.dep -c a.c -o a.o
Running grep Result: ccache.log yields the following:
[2013-06-07T17:46:49.862924 64739] Result: cache miss
[2013-06-07T17:47:03.391406 64860] Result: cache hit (direct)
[2013-06-07T17:47:08.789031 64914] Result: cache miss
Tested on latest master.
From https://bugzilla.samba.org/show_bug.cgi?id=11709:
Test suite fails when building with gcc 6, Fedora development:
CC='gcc' ./test.sh
compiler: /usr/lib64/ccache/gcc
version: gcc (GCC) 6.0.0 20160129 (Red Hat 6.0.0-0.7) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test dir: testdir.15690
starting testsuite base
SUITE: "base", TEST: "-D not hashed" - Expected "cache hit (preprocessed)" to be 14, got 13
cache directory /builddir/build/BUILD/ccache-3.2.4/testdir.15690/.ccache
primary config /builddir/build/BUILD/ccache-3.2.4/testdir.15690/.ccache/ccache.conf
secondary config (readonly) /etc/ccache.conf
cache hit (direct) 0
cache hit (preprocessed) 13
cache miss 40
called for link 2
called for preprocessing 2
multiple source files 1
compiler produced stdout 1
couldn't find the compiler 1
bad compiler arguments 1
unsupported source language 2
unsupported compiler option 1
output to a non-regular file 1
no input file 1
files in cache 3
cache size 12.3 kB
max cache size 5.0 GB
TEST FAILED
Test data and log file have been left in testdir.15690
Makefile:82: recipe for target 'test' failed
ccache has since day 1 (OK, actually day 13: 5f6f501) relied on the fact that GCC and similar enough compilers are able to compile their own preprocessed output with the same outcome as if they compiled the real source code directly.
However, newer versions of GCC no longer quite work this way since they perform an increasing amount of diagnostics analysis only if the source code is compiled directly. The same goes for Clang. It's impossible for ccache to work around this changed behavior in a good way.
The best fix I can think of is to flip the default of run_second_cpp to true. This will solve the problem for all compilers at the expense of some slowdown. For modern compilers the slowdown is measurable but quite tiny, so the improved out-of-the-box experience should be well worth it.
See also the discussion in #93.
From https://bugzilla.samba.org/show_bug.cgi?id=11943:
Is there any reason ccache couldn't support -Wp,-D options?
lz4hc new and fast compress algorithm and it can speed up compilation, by speedup disk reading
with the master branch, when I turned logfile on, the logs are messed up in a single line, so if I have parallel build building object a's log will mix with building object b's log.
even a single line is not integral,
is this expected behavior? thanks
The manual specifies ccache turns off direct mode if “__TIME__” is present in the source code outside comments and string literals. -- but even though the occurrence of TIME is in a trivial comment like this:
// This is a thing. __TIME__ all day long!
ccache logs the following:
[2013-06-07T15:07:04.049076 72838] Found __TIME__ in /path/to/header.h
[2013-06-07T15:07:04.049085 72838] Disabling direct mode
Hello!
Great idea to integrate ccache and memcached! I'll try this.
But seems to be there is missing manual page while installing.
revision - 18ce499
$ ./autogen.sh && ./configure && make && sudo make install
// skipped
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c -m 755 ccache /usr/local/bin
/usr/bin/install -c -d /usr/local/share/man/man1
/usr/bin/install -c -m 644 ./ccache.1 /usr/local/share/man/man1/
/usr/bin/install: cannot stat ‘./ccache.1’: No such file or directory
make: [install] Error 1 (ignored)
I believe manifest.c:390 is searching the wrong hash table:
struct file_stats *st = hashtable_search(hashed_files, path);
Shouldn't that line search stated_files if you want a struct file_stats out of the hash table?
I replaced clang with a script that calls ccache with clang instead. Compiling works, but Xcode does not seem to recognize error messages of the compiler. Actually, it seems like they are frozen in the state they had when the file was compiled for the first time, i.e. new errors do not show up and old errors are still marked in the source files when they already have been resolved.
It seems as if the newly added support for "--serialize-diagnostics" still does not work correctly.
My script works fine when the call to ccache is removed. I used the most current versions of ccache (HEAD of the repository) and Xcode (4.6.2).
The ccache-swig fork, which is part of the swig repository at https://github.com/swig/swig/tree/master/CCache, should be merged into the ccache mainline to prevent duplication of effort.
See discussion in #113.
@itensionanders: Perhaps something you would like to have a look at?
I disabled the i586-mingw32msvc build in ddf5ca4 since GCC 4.2 apparently is too old for proper C99 support, which is required since e527ccc.
@itensionanders: Since you have been working on the mingw build before, do you have any ideas on what would be the best approach? Would it be possible to go back to using gcc-mingw-w64-i686? Or should we make some ugly workaround like (if possible) ignoring the specific error?
Run the following snippet:
echo "int foo() {return 0;}" >/tmp/ctest.cpp
ccache -C
ccache clang -iquote. -c /tmp/ctest.cpp
ccache -C
CCACHE_CPP2=true ccache clang -iquote. -c /tmp/ctest.cpp
The first ccache call will warn about
clang: warning: argument unused during compilation: '-iquote .'
The second will finish without a warning
What happens is, that unlike the correctly supported -I option, the -iquote and -isystem arguments are passed to the compiler together with the preprocessed source.
Executing /usr/bin/clang -iquote. -fcolor-diagnostics -c -o ctest.o /home/***
-iquote and -isystem should be handled the same way as -I flags (excluded when using preprocessed sources). clang does warn about those unused options, gcc doesnt.
The current 3.3.x releases are still not in debian unstable. Given that the freeze for the next release will happen in the coming months, it would be nice to have the actual version included.
From https://bugzilla.samba.org/show_bug.cgi?id=9875:
Windows has a limitation of 8K characters for commands.
Since compilation flags for large projects might exceed this limit (e.g. it has many include paths), @file.opt is commonly used.
The problem is that ccache expands @file and executes the preprocessor with raw arguments. This fails for very long commands...
$ cat test.c
#include <stdio.h>
int main(void) {
#if defined FOO
puts("FOO");
#else
puts("BAR");
#endif
return 0;
}
$ gcc -B -L -DFOO -DBAR -c test.c
$ gcc test.o
$ ./a.out
FOO
$ gcc -B -L -DFOOD -DBAR -c test.c
$ gcc test.o
$ ./a.out
BAR
$ ccache gcc -B -L -DFOO -DBAR -c test.c
$ gcc test.o
$ ./a.out
FOO
$ ccache gcc -B -L -DFOOD -DBAR -c test.c
$ gcc test.o
$ ./a.out
FOO
same problem e.g. with -u -L
From https://bugzilla.samba.org/show_bug.cgi?id=11710:
Especially when sharing a ccache with other users in a large team environment, it can be
difficult to know by whom or when the ccache stats were zeroed. It would be nice for
ccache to print this as part of the stats. For instance:
$ccache -s
ccache stats since Wed Feb 3 18:28:42 EST 2016
cache directory /path/to/dir
primary config /path/to/dir/ccache.conf
secondary config (readonly) /usr/local/etc/ccache.conf
cache hit (direct) 100
cache hit (preprocessed) 100
cache miss 10
...
Output from g++ and ccache: http://paste.ubuntu.com/17091648/
The file i'm compiling is at http://paste.ubuntu.com/17091697/
$ ccache -V
ccache version 3.2.4
$ g++ --version
g++ (Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413
Using Ubuntu 16.04
Any idea why that happens?
Problem with bundled zlib and newer gcc compilers:
zlib/inflate.c: In function 'inflateMark':
zlib/inflate.c:1507:61: error: left shift of negative value [-Werror=shift-negative-value]
if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16;
^~
cc1: all warnings being treated as errors
Workaround: don't use --with-bundled-zlib
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.