Re: Failure building GFortran (Cygwin)

[Angelo Graziosi <angelo dot graziosi at alice dot it>]

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.