[PD-dev] pd-extended / mingw32_nt-5.1_windowsxp-i386

Bryan Jurish moocow at ling.uni-potsdam.de
Sat Aug 11 19:27:37 CEST 2007


moin moin,

it seems that my externals are not building nicely for pd-extended under
mingw32.  The logs say (linebreaks introduced to avoid mailer mangling):

> make \
>  -C /home/pd/auto-build/pd-extended/externals/moocow/extended \
>  pd_src="/home/pd/auto-build/pd-extended/pd" \
>  CFLAGS="-DPD -O2 -mcpu=i586 -mtune=pentium3 \
>   -I/home/pd/auto-build/pd-extended/pd/src \
>   -Wall -W -ggdb -mms-bitfields \
>   -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \
>   -D'drand48()=((double)rand()/RAND_MAX)' \
>   -D'bzero(p,n)=memset(p,0,n)'" \
>  build.stamp \
>  || echo "moocow: WARNING: build failed"
>
> make[3]: Entering directory \
>  `/home/pd/auto-build/pd-extended/externals/moocow/extended'
>
> make[3]: *** No rule to make target `flite.build_stamp', needed by \
>  `build.stamp'.  Stop.
>
> make[3]: Leaving directory \
>  `/home/pd/auto-build/pd-extended/externals/moocow/extended'
>
> moocow: WARNING: build failed

The "build.stamp" target is a literal that depends on a finite number of
generated targets ("deque.build_stamp", "sprinkler.build_stamp", etc.);
the rules for these are generated with GNU make macros and the $(eval
$(call ...)) idiom.  I thought I was safe using GNU make-isms for the
pd-extended build: is this known to be a Bad Idea for mingw32/winxp?

Alternately, can anyone give me a rundown on the precise system
configuration of the build machine (in particular, which version of make
is it running?) so that I can try and debug things from here?

marmosets,
	Bryan

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology




More information about the Pd-dev mailing list