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)
Mike Frysinger writes:
> On 16 Aug 2015 13:39, Tom Lane wrote:
>> and of course "-lz" isn't a valid dependency.
> that's not really true. make will expand it internally into paths like
> /usr/lib/libz.so.
Hmm ... there may be versions of make for which that's true, but
Apple's version (which i
>
> I got a few warnings about assignments of pointers to "bool" values. I
> think these are legitimate gripes, because on platforms where bool is only
> a byte wide, the net effect will be to assign the pointer's low-order byte
> to the bool. There's at least a 1-in-256 chance of a non-null point
Tom Lane wrote:
> [...] this fails to build for me on late-model OS X:
Bummer. Here's my proposed fix:
https://git.samba.org/?p=ccache.git;a=commitdiff;h=f74c76107933046309861680b741adc67ac2a34e.
Perhaps you could try it out?
-- Joel
___
ccache maili
Nadav Har'El wrote:
> [...] Your patch makes ccache exit as soon as it gets the SIGINT - but the
> child compiler might still be running for a while longer. This will usually
> be fine, but I thought the user can be surprised if he sees ccache (which
> he considers to be the compiler) exit, but "
Tom Lane wrote:
>
> Actually, that's a bug not just a cosmetic problem, because it introduces
> a race condition. Consider this sequence of events:
> * make launches "ccache gcc -o test.o test.c"
> * user types control-C
> * ccache receives SIGINT and exits
> * make does unlink("test.o") to clean
>> that's not really true. make will expand it internally into paths like
>> /usr/lib/libz.so.
>
> Hmm ... there may be versions of make for which that's true, but
> Apple's version (which is gnu make 3.81) does not like it.
I think it fails because Apple forgot to change ".LIBPATTERNS",
so that
Joel Rosdahl writes:
>> I got a few warnings about assignments of pointers to "bool" values. I
>> think these are legitimate gripes, because on platforms where bool is only
>> a byte wide, the net effect will be to assign the pointer's low-order byte
>> to the bool.
> Well, as I interpret the C99
