[ccan] Testing ccanlint on Cygwin (gcc 4.3.4-3)
Rusty Russell
rusty at rustcorp.com.au
Tue Mar 8 11:24:26 EST 2011
On Thu, 3 Mar 2011 04:31:29 -0500, Joseph Adams <joeyadams3.14159 at gmail.com> wrote:
> For kicks, I decided to see if I could build CCAN on Windows via
> Cygwin and gcc4. I ran into a few issues. Most (if not all) of them
> are due to issues in the C library used by Cygwin (newlib).
Cool! Thanks!
> * ctype.h functions (islower, toupper, etc.) result in array
> subscript warnings, treated as errors, when passed chars. What else
> would you pass them?
Weird. But such warnigns are not fatal, so I don't think we should be
working around them in CCAN in general.
I would imagine that someone would end up putting a hack in config.h for
this kind of local disaster.
> * strtold (used by ccan_tokenizer) is missing.
Fair enough, that's a C99 function. If you want it to work, you need
to put a configurator test and write a replacement.
> * ssize_t is not defined when <stdlib.h> is included.
Hmm, this is a POSIX definition, and we *should* be including
<sys/types.h> to get it.
Or even better, detecting it in config.h.
> The attached patches work around these issues. The first adds
> ccan_tokenizer to the EXCLUDE list in the Makefile so it won't
> interfere with the build on Cygwin. The second introduces a header
> called compat.h which, if newlib is present, wraps ctype.h functions
> and makes ssize_t available. It then includes "compat.h" at the top
> of several source and header files.
I think adding a compat.h is too fuzzy, and will just balloon out to
an unwieldy mess.
I think should create a specific module for things we need, ie. a
strdold replacement in ccan/str or a specific module (ccan/strtold).
> With that, I got ccan and tools to build, and as many modules that
> were tested passed ccanlint, but failtest seemed to get stuck in an
> infinite loop. When I ran make -j2 check,
> ccan/failtest/test/run-malloc.c and ccan/rbtree/test/run-many.c ended
> up blocking with full CPU each. These infinite loops did not appear
> to consume increasing memory or create a flood of processes.
Hmm, both these are failtest tests. failtest/test/run-malloc.c is
simpler, but it does fork(), kill(getpid(), SIGSEGV) and longjmp which
is a bit funky.
The kill() can be replaced with *p = '\0'. But the rest would have to
be debugged the old-fashioned way, if you have time...
> Other observations:
>
> * Generating inter-depends takes a really long time (about one or two
> minutes), as does test-depends in some cases. This is annoying
> because these files are generated when `make clean` is run. On Linux,
> these build in about a second.
Wow. How annoying. My mid-term plan is to have tools do the build, and
have the Makefile a generated wrapper for it.
> PS: Did my email on February 24 with the subject "A couple patches to
> make tools/ccan_depends --compile work." get through? Both patches
> from that email are still relevant in what they do, but one of them
> will need to be tweaked due to recent commits.
Oops... went back and dug it out. Updated and applied, thanks!
Cheers,
Rusty.
More information about the ccan
mailing list