[ccache] Bail out on -arch?

[Bernhard Bauer]

Hi Joel,

I'm currently trying to get ccache to work under Mac OS X for the
Chromium build. In ccache 3.0pre1, there is a change to bail out early
on the -arch flag, which is used by xcodebuild (the standard OS X
build tool), because it's "too hard". What do you mean by that? Is
there a way to accept the flag if I know that I'm always compiling
with the same -arch option (i.e. i386)? So far I have been using
ccache with -arch without any problems.

Thanks,
Bernhard.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Bail out on -arch?

[Bernhard Bauer]

On Tue, May 11, 2010 at 11:04, Martin Pool  wrote:
> On 11 May 2010 10:47, Bernhard Bauer  wrote:
>> Hi Joel,
>>
>> I'm currently trying to get ccache to work under Mac OS X for the
>> Chromium build. In ccache 3.0pre1, there is a change to bail out early
>> on the -arch flag, which is used by xcodebuild (the standard OS X
>> build tool), because it's "too hard". What do you mean by that? Is
>> there a way to accept the flag if I know that I'm always compiling
>> with the same -arch option (i.e. i386)? So far I have been using
>> ccache with -arch without any problems.
>
> I don't know in detail but the manpage says
>
>       FSF GCC on Darwin does not create "fat" object files; it will
> create an object file for the single architecture that it was built
>       to target.  Apple's GCC on Darwin does create "fat" files if
> multiple -arch options are used; it does so by running the compiler or
>       linker multiple times and joining the results together with lipo.
>
> that sounds potentially complex to me.  Perhaps ccache could at least
> cope with at least the case where only one is given.

I agree, with a single -arch option gcc should behave fully identical.
And even with multiple architectures we should be fine, because ccache
doesn't really depend on the output format of the compiler, as long as
the semantics of how the output file depends on the input files and
the compiler options are the same.

Bernhard.
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Bail out on -arch?

[Martin Pool]

On 11 May 2010 10:47, Bernhard Bauer  wrote:
> Hi Joel,
>
> I'm currently trying to get ccache to work under Mac OS X for the
> Chromium build. In ccache 3.0pre1, there is a change to bail out early
> on the -arch flag, which is used by xcodebuild (the standard OS X
> build tool), because it's "too hard". What do you mean by that? Is
> there a way to accept the flag if I know that I'm always compiling
> with the same -arch option (i.e. i386)? So far I have been using
> ccache with -arch without any problems.

I don't know in detail but the manpage says

   FSF GCC on Darwin does not create "fat" object files; it will
create an object file for the single architecture that it was built
   to target.  Apple's GCC on Darwin does create "fat" files if
multiple -arch options are used; it does so by running the compiler or
   linker multiple times and joining the results together with lipo.

that sounds potentially complex to me.  Perhaps ccache could at least
cope with at least the case where only one is given.

-- 
Martin 
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] About Win32 binary

[asm warrior]

I have just test two version of ccache.exe( one from you and the other
from a codeblocks' forum user reckless).

It seems I still can't use it. I have reported the error build message
in the codeblocks' forum post:

http://forums.codeblocks.org/index.php/topic,12285.msg84932.html#msg84932

It seems ccache can't find the cache folder like:
Unable to determine cache directory

Thanks


On Tue, May 11, 2010 at 8:16 AM, asm warrior  wrote:
> On Tue, May 11, 2010 at 8:08 AM, Ramiro Polla  wrote:
>> You should get the latest source code with git, then apply the patches
>> sequentially, and win32_tests.diff last. Then run "sh autogen.sh",
>> configure and make normally.
> Thanks for the quick response, and I will try it under MinGW and MSYS.
>
>
>>> Is it possible to supply some Win32 binary files, so that a normal
>>> user can use it directly (not build it himself)
>>
>> Here it is:
>> http://ramiro.arrozcru.org/ccache-win32-1.exe
>>
>> It's a build with the exact same patches as I posted on the other
>> thread, cross compiled from Ubuntu, with debugging information. I
>> might remove it at any moment though (sorry to whoever gets here from
>> some search engine and gets frustrated because the link 404s).
>>
>> Ramiro Polla
>
> Nice you have already release a binary. Thanks. I think the debug
> information can simply be removed by strip command.
> I will test it to build the whole Codeblocks IDE project.
> BTW: I have just searched the mail achieve with some keyword "win32
> binary", but get no result. So, I suggest these links can be added to
> the ccache's main home page.
>
> Thanks.
>
> Asmwarrior
>
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] About Win32 binary

[asm warrior]

Hi, Ramiro.
Sorry for the interrupt. I have just find a typo in my command line.
Now, I can successfully using the ccache.exe from reckless's ftp site:
http://ftp//90.184.233.166/ccache.exe

For your ccache.exe, I still failed with the build log:
-- Build: Debug in test_cc_cache ---

[ 50.0%] ccache mingw32-g++.exe -Wall -fexceptions  -g -c
C:\codeblocks_test_code\test_cc_cache\main.cpp -o obj\Debug\main.o
ccache: FATAL: Unable to determine cache directory
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings


Asmwarrior(ollydbg from codeblocks forum)



On Tue, May 11, 2010 at 11:02 PM, asm warrior  wrote:
> I have just test two version of ccache.exe( one from you and the other
> from a codeblocks' forum user reckless).
>
> It seems I still can't use it. I have reported the error build message
> in the codeblocks' forum post:
>
> http://forums.codeblocks.org/index.php/topic,12285.msg84932.html#msg84932
>
> It seems ccache can't find the cache folder like:
> Unable to determine cache directory
>
> Thanks
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] About Win32 binary

[Martin Pool]

On 11 May 2010 17:02, asm warrior  wrote:
> I have just test two version of ccache.exe( one from you and the other
> from a codeblocks' forum user reckless).
>
> It seems I still can't use it. I have reported the error build message
> in the codeblocks' forum post:
>
> http://forums.codeblocks.org/index.php/topic,12285.msg84932.html#msg84932
>
> It seems ccache can't find the cache folder like:
> Unable to determine cache directory

Maybe you need to set the environment variable CCACHE_DIR or HOME?

-- 
Martin 
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] About Win32 binary

[Ramiro Polla]

On Tue, May 11, 2010 at 12:17 PM, asm warrior  wrote:
> Now, I can successfully using the ccache.exe from reckless's ftp site:
> http://ftp//90.184.233.166/ccache.exe

Please tell him he must provide source code for his build.

Also, my patches expect you to be running a shell (not cmd.exe).

Ramiro Polla
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] amd64 buildworld (FreeBSD 8.0p2) consistently fails with ccache

[Joel Rosdahl]

On 2010-05-11 01:38, Christer Edwards wrote:
> I've got another failure (same place) on 3.0pre1.Below are the details:
> 
> I executed 'ccache make buildworld' at /usr/src.

Putting ccache before make doesn't gain anything (but doesn't do any
harm either, except that an error counter in ccache's statistics will be
increased).

> [...]
> [2010-05-10T17:30:38.825974 53291] Running preprocessor
> [2010-05-10T17:30:38.827775 53292] Executing
> /usr/obj/usr/src/tmp/usr/bin/cc -O2 -pipe
> -I/usr/src/lib/csu/i386-elf/../common
> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
> -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c -E
> /usr/src/lib/csu/i386-elf/crt1.c
> [...]
> [2010-05-10T17:30:38.853797 53291] Running real compiler
> [2010-05-10T17:30:38.855228 53294] Executing
> /usr/obj/usr/src/tmp/usr/bin/cc -O2 -pipe
> -I/usr/src/lib/csu/i386-elf/../common
> -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline
> -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c -o
> /usr/.ccache/7/e/00e1bb753cccab0b3367e6287435a8-23935.o.tmp.mouzone.part.net.53291
> /usr/.ccache/tmp/crt1.tmp.mouzone.part.net.53291.i
> [2010-05-10T17:30:38.903089 53291] Compiler gave exit status 1
> [2010-05-10T17:30:38.903377 53291] Copying
> /usr/.ccache/7/e/00e1bb753cccab0b3367e6287435a8-23935.o.tmp.mouzone.part.net.53291
> to crt1.o (uncompressed)
> [2010-05-10T17:30:38.906771 53291] open error: No such file or directory

Nothing strange there, I'm afraid.

Just to make it clear: The build works without ccache, right?

Does it work to run the first command in the log above (after
"Executing"), redirect the output to crt1.i and then run the second
command with "-o crt1.o crt1.i"? If it doesn't work, it's probably a
compiler problem since it can't compile its own preprocessed output. A
workaround for that is to set CCACHE_CPP2 (preferably only when building
the troublesome file). If it works when you run the two commands
manually but not when ccache runs them, then I'm out of guesses.

By the way, I found another thread about the same problem here:
http://www.pubbs.net/200912/freebsd/12812-8-stable-broken-on-amd64.html

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] Bail out on -arch?

[Joel Rosdahl]

On 2010-05-11 13:03, Bernhard Bauer wrote:
> I agree, with a single -arch option gcc should behave fully identical.

The change was made as a "better safe than sorry" reaction to this bug
report: . I didn't
realize that the -arch option was used for one architecture builds.
Here's a fix:

--- a/ccache.c
+++ b/ccache.c
@@ -1214,6 +1214,7 @@ static void process_args(int argc, char **argv,
ARGS **preprocessor_args,
int i;
int found_c_opt = 0;
int found_S_opt = 0;
+   int found_arch_opt = 0;
struct stat st;
/* is the dependency makefile name overridden with -MF? */
int dependency_filename_specified = 0;
@@ -1238,7 +1239,6 @@ static void process_args(int argc, char **argv,
ARGS **preprocessor_args,
strcmp(argv[i], "--coverage") == 0 ||
strcmp(argv[i], "-M") == 0 ||
strcmp(argv[i], "-MM") == 0 ||
-   strcmp(argv[i], "-arch") == 0 ||
strcmp(argv[i], "-fbranch-probabilities") == 0 ||
strcmp(argv[i], "-fprofile-arcs") == 0 ||
strcmp(argv[i], "-fprofile-generate") == 0 ||
@@ -1261,6 +1261,18 @@ static void process_args(int argc, char **argv,
ARGS **preprocessor_args,
}
}

+   /* Multiple -arch options are too hard. */
+   if (strcmp(argv[i], "-arch") == 0) {
+   if (found_arch_opt) {
+   cc_log("More than one -arch compiler option"
+  " is unsupported");
+   stats_update(STATS_UNSUPPORTED);
+   failed();
+   } else {
+   found_arch_opt = 1;
+   }
+   }
+
/* we must have -c */
if (strcmp(argv[i], "-c") == 0) {
args_add(stripped_args, argv[i]);



> And even with multiple architectures we should be fine, because ccache
> doesn't really depend on the output format of the compiler, as long as
> the semantics of how the output file depends on the input files and
> the compiler options are the same.

The problem is that ccache needs to run the preprocessor explicitly, and
that fails when there are multiple -arch options.

-- Joel
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache