[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