bazilxp / ccache-win32 Goto Github PK

The situation could be improved if we define "ccache" as MYNAME2 and 
accept it as a valid base name.

double quote in command line should be escaped.
I didn't find the link of msdn reference yet.

This patch follows python's code:
http://svn.python.org/projects/python/trunk/Lib/subprocess.py list2cmdline()

What steps will reproduce the problem?

Well, I was trying to compile Squid 3.1 under MinGW so:
1. Run CC="ccache gcc" ../configure --blah-blah
2. Fail

checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... ccache
checking whether the C compiler works... no
configure: error: in `/home/USER/squid':
configure: error: C compiler cannot create executables
See `config.log' for more details

CC="gcc" works fine.
config.log doesn't say a great deal.

$ ccache -V
ccache version 2.4
Copyright Andrew Tridgell 2002
Released under the GNU GPL v2 or later

$ ccache -s
cache directory                     C:\Users\USER\AppData\Roaming/.ccac
he
cache hit                              0
cache miss                             0
autoconf compile/link                  4
no input file                         16
files in cache                         0
cache size                             0 Kbytes
max cache size                      20.0 Gbytes

Using Windows 7 64-bit.

when i try made crossbuild from win32 distcc client to many i586mingw-g++
servers with ccache it fails with linking error.

this error only appear when i build qt4 project in the ccache distcc
enviroment. 

output error:

C:\MINGW\BIN\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
cannot find ./build/cmlistdialog.o
collect2: ld returned 1 exit status
mingw32-make[1]: *** [release/cm.dll] Error 1
mingw32-make[1]: Leaving directory `D:/workspace_cpp/cm'
mingw32-make: *** [release] Error 2

What steps will reproduce the problem?
1. Run "make clean all" in an empty directory containing the attached make file.
2. Observe that after the compile step, only "test.o" is listed.
3. Observe that after the link step, still only "test.o" is listed.
4. Observe that after some delay, the "test.exe" becomes available.

What is the expected output? What do you see instead?
After the link step to create "test.exe" is completed, the output file should 
be present and fully built. I was using this make behavior to build a set of 
unit tests, and then run the built tests but this issue breaks that capability.

What version of the product are you using? On what operating system?
This is MinGW 0.3-alpha-2.1, gcc 4.5.2, ccache 2.4

Please provide any additional information below.

It would be nice if ccache-win32 supported MSVC compilers.

I think this is mingw's bug (or limitation), but it is hard to fix in
mingw. So I choice to work around here.

On unix, execv() will replace the current process image with another.
But on window-mingw, it will create another process and terminate current
one. waitpid() will return when old process terminated even the new process
is still running.

For example, bash will run next command before compile output generated.
$ rm -f a.exe; ccache gcc hello.c; ls; sleep 0.1; ls
hello.c
a.exe  hello.c

To work around, I change execv() to CreateProcessA and WaitForSingleObject
using your code snippet from execute.c

After patch, it works as expected
$ rm -f a.exe; ccache gcc hello.c; ls; sleep 0.1; ls
a.exe  hello.c
a.exe  hello.c

[deleted issue]

We can use FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_SEQUENTIAL_SCAN to 
better reflect the way we use them.

Compiling a more or less large project under Windows XP with ccache-2.4-
win32 aborts with a crash dialog ("send problem report to microsoft" - 
dialog) in irregular intervals.

I could trace the problem to the x_realloc code, which looks like this:

/*
  this is like realloc() but dies if the malloc fails
*/
void *x_realloc(void *ptr, size_t size)
{
        void *p2;
        if (!ptr) return x_malloc(size);
        p2 = malloc(size);
        if (!p2) {
                fatal("out of memory in x_realloc");
        }
        if (ptr) {
                memcpy(p2, ptr, size);
                free(ptr);
        }
        return p2;
}

Suppose ptr points to a 100 bytes area of memory and you
reallocate this to 1000000 bytes. Then this line

                memcpy(p2, ptr, size);

will copy 1000000 bytes of data from the old to the new
location, which means that memcpy will read memory far
outside the original allocated area.

I was using a mingw ccache from these sources, when it started complaining
about not being able to unlink files from the Administrator home directory. 

So what should have been happening was deleting stuff from

  C:\Dokumente und Einstellungen\Administrator\.ccache

What happened is that the program interpreted

  dirname("C:\Dokumente und Einstellungen\Administrator/.ccache")

as "C:\Dokumente und Einstellungen" due to the dirname code not properly
seeing "/" as seperator. So this can be fixed by rewriting dirname() as in
the patch I'll attach.