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
