Re: [ccache] ccache version 3.2.3 has been released

2015-08-17 Thread Jürgen Buchmüller
Am Montag, den 17.08.2015, 00:50 -0400 schrieb Mike Frysinger:
 On 16 Aug 2015 13:39, Tom Lane wrote:
  $ 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.
 that's not really true.  make will expand it internally into paths 

FWIW We encountered the same problem when cross compiling from x86_64
for armv[67]l ccache with the Void Linux binary package build system.
Compiling for the native architecture worked as expected.

 that said, there's no value anymore in putting -l flags into the deps 
 and should just omit it from builds.

Yes, please. Simply stripping $(extra_libs) from the dependencies for
ccache$(EXEEXT) solved the issue for us as well.


ccache mailing list

Re: [ccache] BSDiff for cache objects

2012-11-12 Thread Jürgen Buchmüller
Am Montag, den 12.11.2012, 13:49 +0200 schrieb Bogdan Harjoc:
 Basically, before writing a new object file, ccache could find a similar
 object in the cache (based on object-code or source-code hashes for

The main goal of most hashes is to give very distinct results even for
even small changes in the input data, which is why there is not really
an algorithm to compare two files' similarity based on hashes.

Similarity of two files would have to be calculated based on something
that currently isn't available - AFAICT. The savings in size are
probably less important than the expectable performance loss for
building deltas of source and/or object files.


ccache mailing list

Re: [ccache] [PATCH v3] add support for '@' parameters

2012-07-30 Thread Jürgen Buchmüller
Am Montag, den 30.07.2012, 16:05 -0700 schrieb Andrew Boie:
 + /* Trivial case; replace with 1 element */
 + dest-argv[index] = x_strdup(src-argv[0]);

Shouldn't dest-argv[index] be free()d before overwriting it?

 + /* Copy the new arguments into place */
 + for (j = 0; j  src-argc; j++)
 + dest-argv[j + index] = x_strdup(src-argv[j]);

Shouldn't src-argv[j] be free()d after it is strdup()ed?
Or alternatively: why not copy src-argv[j] an re-use it?

The code patch doesn't seem to be too clean.. just my 'feeling' :-P
Excuse me, if I overlooked something essential.


ccache mailing list

[ccache] Suggested patch to add local strtok_r for systems lacking it

2012-04-12 Thread Jürgen Buchmüller
Hi list,

here's a suggested patch for and util.c to add a local
implementation of strtok_r for systems that don't have it (e.g. mingw32
plus libgw32c).


diff -rub ccache-3.1.7.orig/ccache.h ccache-3.1.7/ccache.h
--- ccache-3.1.7.orig/ccache.h	Sun Jan  8 14:40:55 2012
+++ ccache-3.1.7/ccache.h	Thu Apr 12 06:21:36 2012
@@ -97,7 +97,9 @@
 /* - */
 /* util.c */
+#ifndef	HAVE_STRTOK_R
+char* strtok_r(char *src, const char* delim, char** last);
 void cc_log(const char *format, ...) ATTR_FORMAT(printf, 1, 2);
 void cc_log_argv(const char *prefix, char **argv);
 void fatal(const char *format, ...) ATTR_FORMAT(printf, 1, 2);
diff -rub ccache-3.1.7.orig/ ccache-3.1.7/
--- ccache-3.1.7.orig/	Sun Jan  8 14:40:55 2012
+++ ccache-3.1.7/	Thu Apr 12 06:22:17 2012
@@ -64,6 +64,9 @@
 /* Define to 1 if you have a C99 compliant `snprintf' function. */
+/* Define to 1 if you have a C99 compliant `strtok_r' function. */
 /* Define to 1 if you have the stdarg.h header file. */
diff -rub ccache-3.1.7.orig/util.c ccache-3.1.7/util.c
--- ccache-3.1.7.orig/util.c	Sun Jan  8 14:40:55 2012
+++ ccache-3.1.7/util.c	Thu Apr 12 06:20:23 2012
@@ -33,6 +33,53 @@
 #include sys/locking.h
+#ifdef _WIN32
+char * strtok_r(char *s, const char *delim, char **last)
+	char *spanp, *tok;
+	int c, sc;
+	if (s == NULL  (s = *last) == NULL)
+		return (NULL);
+	/*
+	 * Skip (span) leading delimiters (s += strspn(s, delim), sort of).
+	 */
+	c = *s++;
+	for (spanp = (char *)delim; (sc = *spanp++) != 0;) {
+		if (c == sc)
+			goto cont;
+	}
+	if (c == 0) {		/* no non-delimiter characters */
+		*last = NULL;
+		return (NULL);
+	}
+	tok = s - 1;
+	/*
+	 * Scan token (scan for delimiters: s += strcspn(s, delim), sort of).
+	 * Note that delim must have one NUL; we stop if we see that, too.
+	 */
+	for (;;) {
+		c = *s++;
+		spanp = (char *)delim;
+		do {
+			if ((sc = *spanp++) == c) {
+if (c == 0)
+	s = NULL;
+	s[-1] = '\0';
+*last = s;
+return (tok);
+			}
+		} while (sc != 0);
+	}
 static FILE *logfile;
 static bool
ccache mailing list

Re: [ccache] Suggested patch to add local strtok_r for systems lacking it

2012-04-12 Thread Jürgen Buchmüller
Am Donnerstag, den 12.04.2012, 18:54 +1000 schrieb Martin Pool:
 Thanks for the patch.
 I guess the definition ought to be guarded by HAVE_STRTOK_R, not _WIN32.

Of course! I should have looked through it once more before submission.

 Perhaps you also need to update to check for it?

I thought that standard defines, i.e. defines for well known
function names, would be handled automagically by the autotools and it
would suffice to just add the #define. I'll take a closer look now.

In any case, I realized there actually _is_ a strtok_r implementation in
libgw32c - of course! It's just that it was hidden behind a __USE_GNU
ifdef, so I have to specify -D_GNU_SOURCE to enable its visibility.

What I'm trying to achieve is to build ccache-3.1.7 on mingw32 together
with the glibc substitute gw32c. The readily available ccache-win32,
which most people use, is based on ccache-2.4 and a little hackish for
my taste.

Currently I'm running into some brick walls because I must undefine
_WIN32 to avoid conflicts between win32 and glibc for various types and
macros. I will report should I succeed, since I suspect many people will
be interested in a more recent ccache for mingw32.


ccache mailing list