(which is usually in /usr/bin)\&. After installing you may wish to run
"which gcc" to make sure that the correct link is being used\&.
.PP
+Note! Do not use a hard link, use a symbolic link\&. A hardlink will
+cause "interesting" problems\&.
+.PP
.SH "ENVIRONMENT VARIABLES"
.PP
ccache used a number of environment variables to control operation\&. In
update of the modification time on object files that are the result of
the same compilation in a different directory\&.
.IP
-.IP "\fBCCACHE_NOUNIFY\fP"
-If you set the environment variable
-CCACHE_NOUNIFY then ccache will not use the C/C++ unifier when hashing
-the pre-processor output\&. The unifier is slower than a normal hash, so
-setting this environment variable gains a little bit of speed, but it
-means that ccache can\&'t take advantage of not recompiling when the
-changes to the source code consist of reformatting only\&. Note that
-using CCACHE_NOUNIFY changes the hash, so cached compiles with
-CCACHE_NOUNIFY set cannot be used when CCACHE_NOUNIFY is not set and
-vice versa\&.
+.IP "\fBCCACHE_UNIFY\fP"
+If you set the environment variable CCACHE_UNIFY
+then ccache will use the C/C++ unifier when hashing the pre-processor
+output if -g is not used in the compile\&. The unifier is slower than a
+normal hash, so setting this environment variable loses a little bit
+of speed, but it means that ccache can take advantage of not
+recompiling when the changes to the source code consist of
+reformatting only\&. Note that using CCACHE_UNIFY changes the hash, so
+cached compiles with CCACHE_UNIFY set cannot be used when
+CCACHE_UNIFY is not set and vice versa\&. The reason the unifier is off
+by default is that it can give incorrect line number information in
+compiler warning messages\&.
.IP
.PP
.SH "CACHE SIZE MANAGEMENT"
preprocessor output, which means we are sensitive to line number
information. Otherwise we can discard line number info, which makes
us less sensitive to reformatting changes
+
+ Note! I have now disabled the unification code by default
+ as it gives the wrong line numbers for warnings. Pity.
*/
- if (found_debug || getenv("CCACHE_NOUNIFY")) {
+ if (found_debug || !getenv("CCACHE_UNIFY")) {
hash_file(path_stdout);
} else {
if (unify_hash(path_stdout) != 0) {
-#define CCACHE_VERSION "1.7"
+#define CCACHE_VERSION "1.8"
#include "config.h"
(which is usually in /usr/bin). After installing you may wish to run
"which gcc" to make sure that the correct link is being used.
+Note! Do not use a hard link, use a symbolic link. A hardlink will
+cause "interesting" problems.
+
manpagesection(ENVIRONMENT VARIABLES)
ccache used a number of environment variables to control operation. In
update of the modification time on object files that are the result of
the same compilation in a different directory.
-dit(bf(CCACHE_NOUNIFY)) If you set the environment variable
-CCACHE_NOUNIFY then ccache will not use the C/C++ unifier when hashing
-the pre-processor output. The unifier is slower than a normal hash, so
-setting this environment variable gains a little bit of speed, but it
-means that ccache can't take advantage of not recompiling when the
-changes to the source code consist of reformatting only. Note that
-using CCACHE_NOUNIFY changes the hash, so cached compiles with
-CCACHE_NOUNIFY set cannot be used when CCACHE_NOUNIFY is not set and
-vice versa.
+dit(bf(CCACHE_UNIFY)) If you set the environment variable CCACHE_UNIFY
+then ccache will use the C/C++ unifier when hashing the pre-processor
+output if -g is not used in the compile. The unifier is slower than a
+normal hash, so setting this environment variable loses a little bit
+of speed, but it means that ccache can take advantage of not
+recompiling when the changes to the source code consist of
+reformatting only. Note that using CCACHE_UNIFY changes the hash, so
+cached compiles with CCACHE_UNIFY set cannot be used when
+CCACHE_UNIFY is not set and vice versa. The reason the unifier is off
+by default is that it can give incorrect line number information in
+compiler warning messages.
enddit()
void hash_buffer(const char *s, int len)
{
- static char tail[64];
- static int tail_len;
-
- /* s == NULL means push the last chunk */
- if (s == NULL) {
- if (tail_len > 0) {
- mdfour_update(&md, (unsigned char *)tail, tail_len);
- tail_len = 0;
- }
- return;
- }
-
- if (tail_len) {
- int n = 64-tail_len;
- if (n > len) n = len;
- memcpy(tail+tail_len, s, n);
- tail_len += n;
- len -= n;
- s += n;
- if (tail_len == 64) {
- mdfour_update(&md, (unsigned char *)tail, 64);
- tail_len = 0;
- }
- }
-
- while (len >= 64) {
- mdfour_update(&md, (unsigned char *)s, 64);
- s += 64;
- len -= 64;
- }
-
- if (len) {
- memcpy(tail, s, len);
- tail_len = len;
- }
+ mdfour_update(&md, (unsigned char *)s, len);
}
-
void hash_start(void)
{
mdfour_begin(&md);
md->C = 0x98badcfe;
md->D = 0x10325476;
md->totalN = 0;
+ md->tail_len = 0;
}
m = md;
+ if (in == NULL) {
+ mdfour_tail(md->tail, md->tail_len);
+ return;
+ }
+
+ if (md->tail_len) {
+ int len = 64 - md->tail_len;
+ if (len > n) len = n;
+ memcpy(md->tail+md->tail_len, in, len);
+ md->tail_len += len;
+ n -= len;
+ in += len;
+ if (md->tail_len == 64) {
+ copy64(M, md->tail);
+ mdfour64(M);
+ m->totalN += 64;
+ md->tail_len = 0;
+ }
+ }
+
while (n >= 64) {
copy64(M, in);
mdfour64(M);
m->totalN += 64;
}
- mdfour_tail(in, n);
+ if (n) {
+ memcpy(md->tail, in, n);
+ md->tail_len = n;
+ }
}
}
-void mdfour(unsigned char *out, unsigned char *in, int n)
+void mdfour(unsigned char *out, const unsigned char *in, int n)
{
struct mdfour md;
mdfour_begin(&md);
mdfour_update(&md, in, n);
+ mdfour_update(&md, NULL, 0);
mdfour_result(&md, out);
}
{
int fd, i;
struct mdfour md;
- unsigned char buf[64*1024], sum[16];
+ unsigned char buf[1024], sum[16];
+ unsigned chunk;
fd = open(fname,O_RDONLY);
if (fd == -1) {
perror("fname");
exit(1);
}
+
+ chunk = 1 + random() % (sizeof(buf) - 1);
mdfour_begin(&md);
while (1) {
- int n = read(fd, buf, sizeof(buf));
+ int n = read(fd, buf, chunk);
if (n >= 0) {
mdfour_update(&md, buf, n);
}
- if (n < sizeof(buf)) break;
+ if (n < chunk) break;
}
close(fd);
+ mdfour_update(&md, NULL, 0);
+
mdfour_result(&md, sum);
for (i=0;i<16;i++)
struct mdfour {
uint32 A, B, C, D;
uint32 totalN;
+ unsigned char tail[64];
+ unsigned tail_len;
};
void mdfour_begin(struct mdfour *md);
void mdfour_update(struct mdfour *md, const unsigned char *in, int n);
void mdfour_result(struct mdfour *md, unsigned char *out);
-void mdfour(unsigned char *out, unsigned char *in, int n);
+void mdfour(unsigned char *out, const unsigned char *in, int n);
This will work as long as /usr/local/bin comes before the path to gcc
(which is usually in /usr/bin). After installing you may wish to run
"which gcc" to make sure that the correct link is being used.
+<p>Note! Do not use a hard link, use a symbolic link. A hardlink will
+cause "interesting" problems.
<p><h2>ENVIRONMENT VARIABLES</h2>
<p>ccache used a number of environment variables to control operation. In
instead. The main reason for setting this option is to avoid the
update of the modification time on object files that are the result of
the same compilation in a different directory.
-<p><p></p><dt><strong><strong>CCACHE_NOUNIFY</strong></strong><dd> If you set the environment variable
-CCACHE_NOUNIFY then ccache will not use the C/C++ unifier when hashing
-the pre-processor output. The unifier is slower than a normal hash, so
-setting this environment variable gains a little bit of speed, but it
-means that ccache can't take advantage of not recompiling when the
-changes to the source code consist of reformatting only. Note that
-using CCACHE_NOUNIFY changes the hash, so cached compiles with
-CCACHE_NOUNIFY set cannot be used when CCACHE_NOUNIFY is not set and
-vice versa.
+<p><p></p><dt><strong><strong>CCACHE_UNIFY</strong></strong><dd> If you set the environment variable CCACHE_UNIFY
+then ccache will use the C/C++ unifier when hashing the pre-processor
+output if -g is not used in the compile. The unifier is slower than a
+normal hash, so setting this environment variable loses a little bit
+of speed, but it means that ccache can take advantage of not
+recompiling when the changes to the source code consist of
+reformatting only. Note that using CCACHE_UNIFY changes the hash, so
+cached compiles with CCACHE_UNIFY set cannot be used when
+CCACHE_UNIFY is not set and vice versa. The reason the unifier is off
+by default is that it can give incorrect line number information in
+compiler warning messages.
<p></dl>
<p><h2>CACHE SIZE MANAGEMENT</h2>