Bug 7401 - Preprocessor error on universal build
Preprocessor error on universal build
Product: ccache
Classification: Unclassified
Component: ccache
All Mac OS X
: P5 enhancement
: ---
Assigned To: Joel Rosdahl
Joel Rosdahl
Depends on:
  Show dependency treegraph
Reported: 2010-04-30 08:56 UTC by Florian Doersch
Modified: 2014-04-09 18:56 UTC (History)
0 users

See Also:

the patch as attachment (979 bytes, patch)
2010-04-30 08:57 UTC, Florian Doersch
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Doersch 2010-04-30 08:56:57 UTC

at the moment, if I try to build with multiple -arch flags (so i create an universal binary) ccache only reports "preprocessor error" in the ccache-stats (on 2.4 and 3.0pre0)

I made a little (perhaps not so clean) patch for 2.4 to strip out the -arch parameters on the preprocessor run:

--- ccache.c.orig	2004-09-13 12:38:30.000000000 +0200
+++ ccache.c		2010-04-30 15:45:43.000000000 +0200
@@ -363,11 +363,27 @@
 	x_asprintf(&path_stderr, "%s/tmp.cpp_stderr.%s", temp_dir, tmp_string());
 	if (!direct_i_file) {
+		int i = 0;
+		ARGS *nargs = args_init(args->argc, args->argv);
 		/* run cpp on the input file to obtain the .i */
-		args_add(args, "-E");
-		args_add(args, input_file);
-		status = execute(args->argv, path_stdout, path_stderr);
-		args_pop(args, 2);
+		args_add(nargs, "-E");
+		args_add(nargs, input_file);
+		/* remove -arch parameters */
+		for(i = 0; i < nargs->argc;)
+		{
+			if(strcmp(nargs->argv[i], "-arch") == 0)
+			{
+				strcpy(nargs->argv[i++],"");
+				strcpy(nargs->argv[i],"");
+			}
+			else
+				++i;
+		}
+		status = execute(nargs->argv, path_stdout, path_stderr);
+		/*args_pop(args, 2);*/
 	} else {
 		/* we are compiling a .i or .ii file - that means we
 		   can skip the cpp stage and directly form the

(i hope the whitespaces are not stripped here)
Comment 1 Florian Doersch 2010-04-30 08:57:34 UTC
Created attachment 5675 [details]
the patch as attachment
Comment 2 Joel Rosdahl 2010-05-05 14:02:56 UTC

I don't know much about Mac OS X, but does your patch really preserve the semantics of the compiler? I.e., will

    gcc -arch x -arch y -c foo.c -o foo.o


    gcc -c foo.c -E -o foo.i
    gcc -arch x -arch y -c foo.i -o foo.o

always give the same foo.o?

The reason I'm asking is that apparently there was some work made in 2006 by David Vasilevsky to fix the same problem:


His repository seems to be gone, but you can read the commits here:


The changes he made seem to be much more complicated than your fix. Do you have any thoughts about his approach?
Comment 3 Florian Doersch 2010-05-05 14:48:37 UTC
yes I think its not as easy as I thought,
My first approach was not working correctly. I will look at the code you mentioned, perhaps I can change my patch so it will work (or simply use the multiarch-stuff)
Comment 4 Florian Doersch 2010-09-24 04:19:29 UTC

I don't know if here's some progress on that topic, but I've created a little wrapper (like ccache itself) for ccache and universal-builds


its really quick&dirty solution, but it works for my cross-compilers and my use-case (called via cmake)

perhaps someone can use it to create a universally working solution
Comment 5 Joel Rosdahl 2013-01-05 17:30:03 UTC
Florian, any news on this issue? Perhaps it should be closed?
Comment 6 Florian Doersch 2013-01-05 18:36:02 UTC
well, I use the ccache_lipo I wrote "instead" of ccache for multi-arch compiles and that works fine.

ccache_lipo does nothing else than splitting the command line (filtering out -arch parameters) and call the (ccache)-compiler for each arch, and "lipo" them at the end. perhaps someone can integrate it into ccache directly.
Comment 7 Joel Rosdahl 2014-04-09 18:56:14 UTC
Closing this as WONTFIX.