moin Hans, moin list,
On 2009-04-20 02:10:17, Hans-Christoph Steiner hans@eds.org appears to have written:
On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote:
moin Hans, On 2009-04-18 06:57:53, Hans-Christoph Steiner hans@eds.org appears to have written:
The bad news is that it seems that my bad diagnosis led you on a wide goose chase thru the pain of Windows development.
It may or may not have been a bad diagnosis (although it certainly was a pain ;-) -- I still haven't verified the former, since I don't use (or understand) all of the auto-build scripts. I'm still kinda hoping IOhannes might make some headway there...
You don't really need to understand the auto-build scripts, all that needs to work is this:
cd pure-data/externals make moocow make moocow_install
yup, I've understood that bit (and the motivations, I think). I meant that since the problems arising in 'make moocow' appear to have been *due to* clever & fiendish details of earlier scripts (e.g. use of rsync rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have behooved me to have understood those scripts better (e.g. at all)...
Apparently, string2any and friends are still not getting built. In fact all of the 'moocow' is empty on Windows.
This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale):
configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -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)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c >&5 <command line>:4:1: macro names must be identifiers <command line>:5:1: macro names must be identifiers <command line>:6:1: macro names must be identifiers <command line>:7:1: macro names must be identifiers configure:2704: $? = 1 configure:2742: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "locale" | #define PACKAGE_TARNAME "locale" | #define PACKAGE_VERSION "0.02-1" | #define PACKAGE_STRING "locale 0.02-1" | #define PACKAGE_BUGREPORT "moocow@ling.uni-potsdam.de" | #define PACKAGE "locale" | #define VERSION "0.02-1" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2749: error: C compiler cannot create executables
... newline escapes in the gcc call added post-hoc for legibility. The above call works fine (creating a.exe) by hand on the build farm win32 machine with "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" prepended to PATH, so I can't grok where things might be going wrong, much less what the "macro names must be identifiers" errors are all about -- assumedly some of the '-D' flags are giving me grief, but since I can't reproduce the error, I can't tell which ones or what to do about it.
Anyone have any ideas?
I can't use rdesktop currently, since it's telling me I'd have to kick out another user (pd).
In a related question, should the auto-build process for the win32 build-farm machine be trying to build everything from the LIB_TARGETS variable in externals/Makefile? If so, then I must be being pretty dense, because I can't see where my builds are getting called (I see install calls, but no configuration or compilation), much less where they might be failing...
You are correct. Search for 'moocow_install:' in externals/Makefile. That's where its being called.
Yes, right; but I couldn't see (until the rsync fix/hack was applied) where the 'moocow' target was getting called, thus recursing into externals/moocow/extended. That's showing up now, so no worries.
marmosets, Bryan
Bryan Jurish wrote:
This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale):
configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -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)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c >&5 <command line>:4:1: macro names must be identifiers <command line>:5:1: macro names must be identifiers <command line>:6:1: macro names must be identifiers <command line>:7:1: macro names must be identifiers
I'm guessing here but it looks like the 4th, 5th 6th and 7th defines in the command line are causing trouble. Indeed they are not identifiers as such, they are just strings. One thing that looks odd is the single quote '' instead of the more commonly used "". Without knowing what that particular combo of gcc and shell most enjoys, I would change that and see what happens next.
Martin
moin all,
Good call, Martin: thanks!
In case anyone else runs into this or something similar, here are some gory details:
It turns out that both single and double quotes cause ./configure to spit, and my initial inability to reproduce the error here was just me being dense, sleepy, etc. It seems that since autoconf's CFLAGS variable (and its value) has to do double-duty as both a shell (as called by ./configure) and a make variable, *any* kind of quotes are "graphema non grata", unless you do something horrid like setting CC="eval gcc" ;-)
Contrast the shell script: | #!/bin/sh | CFLAGS="-g -D'UglyQuotedMacro=1'" | gcc $CFLAGS conftest.c
with the Makefile: | CFLAGS=-g -D'UglyQuotedMacro=1' | a.out: ; gcc $(CFLAGS) conftest.c
for a dummy C file "conftest.c": | int main (void) { return 0; }
... the shell script pukes, but make runs fine, since the make variable gets passed through an additional shell evaluation. So the problem was indeed the -D'whatever' macros getting passed into ./configure by make. Duh...
Not sure how to fix this the "right" way (or even if that's possible): for now I'm just assuming that all relevant flags don't contain any spaces or other characters needing escapes, and that seems to work well on the build farm machine (tested locale and pdstring only so far).
marmosets, Bryan
On 2009-04-25 03:13:24, Martin Peach martin.peach@sympatico.ca appears to have written:
Bryan Jurish wrote:
This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale):
configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -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)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c >&5 <command line>:4:1: macro names must be identifiers <command line>:5:1: macro names must be identifiers <command line>:6:1: macro names must be identifiers <command line>:7:1: macro names must be identifiers
I'm guessing here but it looks like the 4th, 5th 6th and 7th defines in the command line are causing trouble. Indeed they are not identifiers as such, they are just strings. One thing that looks odd is the single quote '' instead of the more commonly used "". Without knowing what that particular combo of gcc and shell most enjoys, I would change that and see what happens next.