old but current libiberty/strsignal vs. cygwin

[Jay <jay dot krell at cornell dot edu>]

strsignal problems on target=Cygwin have been kicking around for years.

This is a libiberty issue.
Maybe offtopic for gcc.
Or maybe the right place.
?
(and gcc vs. gcc-patches, similar, opening a bug seems too
heavyweight when an analysis/fix is (mostly) in hand..)

native cygwin (build=host=target=cygwin, or at least target=cygwin)
 gcc 4.3.2 (recently released)
 + binutils 2.18
 + cygwin-snapshot-20080822-1
   This is winsup and newlib.
 + gmp 4.2.3, mpfr, 2.3.1
 once nice unified tree

some or all slightly patched -- to fix build problems


The error is:


# /src/gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal'
#   const char *
#   strsignal (int signo)
#
# /src/gcc/newlib/libc/include/string.h:79: error: previous declaration of 'strsignal' was here
#   char  *_EXFUN(strsignal, (int __signo));
#
# make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-cygwin/i686-pc-cygwin/libiberty'


It's a bit involved.
libiberty endeavors to avoid probing for strsignal, and provide its own,
for a cygwin target, in order for cygwin's strsignal to be libiberty's strsignal.
That's what the comments say, and I believe they match the code (shown below).
That is, the probe would succeed, thereby not contributing the very implementation needed.


However back in 2004, cygwin got its own strsignal:
  http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strsig.cc?cvsroot=src
  http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?r1=1.153&r2=1.154&cvsroot=src


Current libiberty though:
 http://gcc.gnu.org/svn/gcc/trunk/libiberty/configure.ac


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


This appears outdated.

Try changing it to:
      checkfuncs="`echo $checkfuncs | sed -e 's/psignal//'`"


That does not fix the problem however.
Though I presume it is reasonable.
That does doesn't run, I think, because of of setjobs (though my sh/test
isn't strong enough to be certain...ugh):


if test -n "${with_target_subdir}"; then


  # We are being configured as a target library.  AC_REPLACE_FUNCS
  # may not work correctly, because the compiler may not be able to
  # link executables.  Note that we may still be being configured
  # native.


  # If we are being configured for newlib, we know which functions
  # newlib provide and which ones we will be expected to provide.


  if test "x${with_newlib}" = "xyes"; then
...
    setobjs=yes


  fi


Instead see here, same file:


case "${host}" in
  *-*-cygwin* | *-*-mingw*)
    AC_DEFINE(HAVE_SYS_ERRLIST)
    AC_DEFINE(HAVE_SYS_NERR)
    ;;
esac


and change it to:


case "${host}" in
  *-*-mingw*)
    AC_DEFINE(HAVE_SYS_ERRLIST)
    AC_DEFINE(HAVE_SYS_NERR)
    ;;


  *-*-cygwin*)
    AC_DEFINE(HAVE_SYS_ERRLIST)
    AC_DEFINE(HAVE_SYS_NERR)
    #
    # Cygwin used to use libiberty's strsignal, but
    # got its own in 2004.
    #
    AC_DEFINE(HAVE_STRSIGNAL)
    ;;
esac


 I'm still testing this but it does seem to be two smoking guns.
 The first one shot a blank but I doubt I'll find a third. :)


 Nobody builds gcc + cygwin in an integrated tree?
 I wish I could integrate more into The One Tree.
 I so dislike everything being separate..

Can someone vet and apply these changes? Thanks.

In the meantime, I wrap up my build with something that applies
various patches and workarounds (attached).

Similarly, this is kind of yucky but I guess ok:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: au
to-importing has been activated without --enable-auto-import specified on the co
mmand line.
This should work unless it involves constant data structures referencing symbols
 from auto-imported DLLs.Info: resolving _sys_nerr by linking to __imp__sys_nerr
 (auto-import)
Info: resolving _sys_errlist by linking to __imp__sys_errlist (auto-import)

This is probably libiberty/strerror.c.
Must it declare them itself? Always?
Configure it and only declare if not otherwise declared?
Might be general goodness to avoid declaring stuff one's self?
Or declare them __declspec(dllimport) on Cygwin (or whatever is the gcc equiv).


Thanks,
 - Jay

Attachment: build.py
Description: Text document