Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]

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

[ DJ Delorie Cc'd in as libiberty maintainer ]

    Hi DJ,

  We're having a bit of build trouble for GCC HEAD on Cygwin: to recap, ...

> Dave Korn wrote:
>> Andy Scott wrote:
>
>>> ../../../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

>>   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?


  I've now reproduced this myself, and what's happening is that libiberty
configure correctly detects that cygwin has strsignal when it's building it as
a host lib, but when it comes to build it as a target library in stage 3 the
detection fails and we get these conflicting definitions.  I looked at what
was going on and there's this chunk of code with your name on it, so I hope
you can help me understand it, although it looks like it's very old code, so I
won't blame you if it doesn't ring any bells!

libiberty/configure.ac:570
--------------------------------<snip>--------------------------------
if test -z "${setobjs}"; then

  case "${host}" in

  *-*-cygwin*)
    # The Cygwin library actually uses a couple of files from
    # libiberty when it is built.  If we are building a native
    # Cygwin, and we run the tests, we will appear to have these
    # files.  However, when we go on to build winsup, we will wind up
    # with a library which does not have the files, since they should
    # have come from libiberty.

    # We handle this by removing the functions the winsup library
    # provides from our shell variables, so that they appear to be
    # missing.

    # DJ - only if we're *building* cygwin, not just building *with* cygwin

    if test -n "${with_target_subdir}"
    then
      funcs="`echo $funcs | sed -e 's/random//'`"
      AC_LIBOBJ([random])
      vars="`echo $vars | sed -e 's/sys_siglist//'`"
      checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
    fi
    ;;
--------------------------------<snip>--------------------------------

  Your comment says "only if we're building cygwin", but I think what the
effect of testing with_target_subdir really amounts to is a test of whether
we're building libiberty as a cygwin target library, isn't it?  In any case,
this clause is kicking in during stage3 (but not during stage1-2) of a native
cygwin build and causing strsignal to be removed from checkfuncs, with the
result that it ends up being defined by libiberty.

  I've tried removing the "-e 's/strsignal//'" option to sed, and it fixes
the gcc build problem.  I've tried removing it from libiberty in winsup and
libiberty in binutils and they both build ok without it.  Is it possible the
entire clause isn't needed any more?  I can't find any sign that the
winsup/cygwin dir refers to any libiberty files any more, and this entry (from
winsup/cygwin/ChangeLog-2007)

2007-07-08  Christopher Faylor

	* Makefile.in (DLL_OFILES): Add newly-imported random.o.  Eliminate
	reliance on libiberty.
	* random.cc: Import from FreeBSD.  Modify for Cygwin environment.
	* include/cygwin/stdlib.h (random): Reflect change in return value to
	be more linux/freebsd-like.
	(srandom): Ditto.

... suggests that it's no longer the case at all.  So I would appreciate any
advice you can offer about whether it would be better if I submit a patch to
just tweak the sed command to fix this particular problem, or if you'd prefer
that I tested removing the whole clause and sent a patch for that instead?

    cheers,
      DaveK