Failure building GFortran (Cygwin)

[Angelo Graziosi]

Eric Blake ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Jerry DeLisle on 6/29/2008 11:45 AM:
> | Ian Lance Taylor wrote:
> |> CC'ed to Eric.  This may require some configury patches somewhere.
> |>
> |>>>>     Adjust strsignal to POSIX 200x prototype.
> |>>>>     * strsignal.c (strsignal): Remove const.
> |>>>   You may need to build and install cygwin from CVS[*] to get the
> |>>> corresponding newlib fix and install it into your system headers in
> |>>> /usr/include.  Or you could patch your /usr/include/string.h
> |>>> locally.
> |>>>
> |>
> | A PR should be opened for this. Has that been done?  Is it marked as a
> | regression and as a blocker?
> 
> Sorry for the delay in responding; this mail landed in my inbox while I
> was on vacation.  An even more fundamental question (but one that still
> needs a PR, if you haven't created one yet) - when building libiberty on
> cygwin, why does it even trying to compile a strsignal replacement, since
> cygwin has already been providing strsignal implemented in C++ for years?
> ~ In other words, there should be no need to compile libiberty's
> strsignal.c, thus it should not matter whether you are using the 1.5.x
> (broken) string.h, or the 1.7.0 (fixed) prototype.
> 
> |
> | Who has responsibility to fix this?
> 
> Unfortunately, I've never compiled Fortran myself, and my experience with
> libiberty is very limited.  I don't know why the libiberty configury isn't
> picking up on the fact that cygwin already has strsignal.
> 

The first workaround (suggested by Paul) was to re-add the 'const'. Now, 
after what Eric wrote, the following passes the bootstrap of current 
gcc-4.4-20080711 (only C,Fortran):

--- strsignal.c.orig    2008-06-19 17:08:53.000000000 +0200
+++ strsignal.c 2008-07-12 11:18:53.687500000 +0200
@@ -402,7 +402,7 @@

  */

-#ifndef HAVE_STRSIGNAL
+#if !defined (HAVE_STRSIGNAL) && !defined (__CYGWIN__)

  char *
  strsignal (int signo)


But is it the correct solution?

In libiberty/configure.ac I find:

-----------------------------
[...]
   *-*-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
     ;;
[...]
-----------------------------

So, perhaps, you have better and elegant solution!


Cheers,
    Angelo.