Re: This is a Cygwin failure yeah?

["Dave Korn" <dave dot korn dot cygwin at googlemail dot com>]

Andy Scott wrote:

> When it gets to stage 3 (after many hours) I get the following printed
> out to the console (not redirected) -
>
> 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error
> while dumping state (probably corrupted stack)
>
> By the looks of this I wold say that some part of the Cygwin runtime
> has failed.

  To be precise: what this means is that firstly a user application has
failed with a segfault or some similar error that would normally produce a
.stackdump file (Cygwin's equivalent of dumping core when an application
fails), but that there has been an exception in the code that tries to unwind
the stack and generate the dumpfile.  So it could be a Cygwin runtime failure,
or it could just be a particularly bad crash in whatever application was
running at the time.

> I've not seen this one in Cygwin at any other time than
> building GCC which leads me to assume (which is dangerous I realise)
> that there is an issue with my version and how GCC builds. Placing the
> "blame" on the Cygwin runtime.
>
> Is this a correct assumption can anyone tell me?

  It could be, but it could also be a bad codegen bug in the new compiler
you're building.  You haven't given enough context to tell exactly where it's
happening, but since we're in stage 3 and the executable is called 'conftest',
it could be one of the configure test programs built with the new compiler
when configuring to build the target libraries.

  Another possibility is that it's not even actually a problem at all.  It
may well be that this is a configure test for some feature that isn't
implemented or doesn't work on Cygwin and configure is correctly deducing that
attempts to use it will fail.

> GCC Build One:
>
> Again stage3 part of build, and this is what actually stops the build
> the above issue doesn't seem to (I think it happens in stage 2),

  That sentence contradicts itself and what you said earlier, doesn't it?

> ../../../gcc/libiberty/strsignal.c -o strsignal.o
> ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal'
> /usr/include/string.h:78: note: previous declaration of 'strsignal' was here
> make[2]: *** [strsignal.o] Error 1
> make[2]: Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty'
> make[1]: *** [all-target-libiberty] Error 2
> make[1]: Leaving directory `/home/andy/live-gcc/my_gcc'
> make: *** [all] Error 2
>
> Which seems like a possible setup/build issue. If this is so anyone
> seen it before and any helpful hints on how to get rid of it?

  Looks like newlib has a non-posix-compliant definition of strsignal.  If
you take a look at the header file, it seems GDB has a problem with it too:

/tmp/binutils/binutils-2.19/ld $ cat -n /usr/include/string.h | grep -C4 78
    74  char    *_EXFUN(strlwr,(char *));
    75  char    *_EXFUN(strupr,(char *));
    76  #ifdef __CYGWIN__
    77  #ifndef DEFS_H  /* Kludge to work around problem compiling in gdb */
    78  const char  *_EXFUN(strsignal, (int __signo));
    79  #endif
    80  int     _EXFUN(strtosigno, (const char *__name));
    81  #endif
    82
/tmp/binutils/binutils-2.19/ld $

... maybe just adding -DDEFS_H to your CFLAGS would be a work-around.  Hmm,
given that Cygwin supports strsignal, this bit of libiberty shouldn't be being
compiled, because configure should have defined HAVE_STRSIGNAL.  On my local
build of 4.3.2, this works correctly: "nm libiberty/strsignal.o" shows the
function isn't defined, and HAVE_STRSIGNAL is defined in config.h.  Have a
look through libiberty/config.log and see if you can figure out why it isn't
defined; maybe it's even something to do with the earlier crash?

    cheers,
      DaveK