The CPPFLAGS problem isn't cool, but if your description is accurate, 
it's using cpp-precomp in all cases; the regular pre-processor doesn't 
get used unless you ask for it.  This is surprising because in the 
Darwin build, we override CFLAGS, and I have to ensure that -DFOO flags 
and so on are in CPPFLAGS, not CFLAGS, else the build fails.

   Note that there are no special threading flags for the compiler needed 
in Darwin.  Adding thread support probably adds code, so that may 
explain why you get a different (broken?) perl.  I've not tried threads.

	-Fred

On Wednesday, January 30, 2002, at 09:39  AM, Arthur Bergman wrote:

>  On MacOSX
> 
>  When building with threads I get
> 
>  cpp error, trying with -no-precomp-cpp
> 
>  When build without threads I don't
> 
>  The command cc -DPERL_CORE -c -pipe -fno-common -DINT32_MIN_BROKEN 
>  -DINT64_MIN_BROKEN -fno-strict-aliasing -O3 -Wall miniperlmain.c
> 
>  is issued in both cases, one results in mayham (threading), one does 
>  not.
> 
>  The case seems to be that cppflags is NEVER passed to cc at all, but 
>  something that is only included when threading is on forces the cpp to 
>  go to "advanced" mode?
> 
>  Infact from looking thru the makefile the cppflags seems to be totally 
>  ignored for anything else than makedepend and myconfig
> 
>  I assume the correct fix is to properly pass ccpflags, is it 
>  interesting to find out why we suddenly start failing when threads are 
>  included?
> 
>  Interesting to note that this also applies to MakeMaker since it 
>  doesn't pass cppflags to cc on darwin.
> 
>  Arthur
> 
>  ps, I now have bug 2850918 and 2850901 in Apples bugtracking