Dave Nadler wrote: > - decipher the build complaint below and suggest what I've screwed up, or
The problem is that CFLAGS contains -Werror which turns any minor warning into a fatal error that stops the build. > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -g -O2 -Wall > -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > -Wstrict-prototypes -Wwrite-strings -fno-strict-aliasing -MT cols.o -MD -MP > -MF .deps/cols.Tpo -c -o cols.o cols.c > In file included from cols.c:3: > columns.c: In function `handleIndent': > columns.c:169: warning: int format, long unsigned int arg (arg 3) > columns.c:169: warning: int format, long unsigned int arg (arg 3) Indeed columns.c contains: 156 uint32_t colCt = strtoul( pzIndentArg, &pz, 0 ); ... 169 fprintf( stderr, "Cannot malloc %d bytes\n", colCt + 1 ); This provokes a warning on Cygwin (where uint32_t is a typedef for "unsigned long") whereas it does not on Linux where uint32_t is a typedef for "unsigned int". The warning has correctly pointed out the error in assuming that uint32_t is based on the "int" type, which is not a portable assumption. Even though Cygwin is an ILP32 system, consider platforms (like avr for example) where int is 16 bits and so uint32_t would also be based on "long" or some other type. The only portable way to use uint32_t with printf is by using the corresponding format specifier define from inttypes.h, i.e. fprintf( stderr, "Cannot malloc %"PRIu32" bytes\n", colCt + 1 ); This of course has its own set of portability issues since inttypes.h isn't available everywhere. Perhaps a better option would be to use size_t and %zu. These is good example of why it's a bad idea to ship software with -Werror enabled by default. It might be helpful for the developer of the package to have it enabled but it is certainly unhelpful to the end user who is just trying to use the software. For this reason it's traditional to have a --{en,dis}able-werror configure option that allows for the end-user to override the package, however it seems that autogen does not share this philosophy but instead forces -Werror. Ouch. This is a new development, so I'd say one workaround would be to simply use an older version. 5.9.5 should be fine. You could also edit configure.in and regenerate configure. > - alternatively, provide an executable ready to go on win32... The problem with getting autogen working with Cygwin lies in libguile. The binary version provided by the distro was built with an incompatible version of gcc and so autogen built against it segfaults at startup. It's been reported multiple times but the guile maintainer is still in denial that a problem exists. So, you need to build guile yourself from source. Brian ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Autogen-users mailing list Autogen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/autogen-users