old but current libiberty/strsignal vs. cygwin

Jay jay.krell@cornell.edu
Sun Sep 14 14:45:00 GMT 2008 


From my build wrapper...:



#
# /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'
#
# and:
#   char *
#   /src/cygwin-snapshot-20080822-1/newlib/libc/sys/linux/strsignal.c(43):strsignal (int sig)
#   extern "C" char *
#   /src/cygwin-snapshot-20080822-1/winsup/cygwin/strsig.cc(77):strsignal (int signo)
#
# appears to be a autoconfiguration problem?
#
# /src/gcc/libiberty/configure:
#
#  *-*-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//'`"
#      case $LIBOBJS in
#    "random.$ac_objext"   | \
#  *" random.$ac_objext"   | \
#    "random.$ac_objext "* | \
#  *" random.$ac_objext "* ) ;;
#  *) LIBOBJS="$LIBOBJS random.$ac_objext" ;;
#esac
#
#      vars="`echo $vars | sed -e 's/sys_siglist//'`"
#      checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
#    fi
#    ;;
#
# Cygwin got its own strsignal back in 2004, so libiberty should no longer provide it.
#  That is, it should let autoconfiguration work.
# 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
# http://gcc.gnu.org/svn/gcc/trunk/libiberty/configure.ac
#
# < checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
#> checkfuncs="`echo $checkfuncs | sed -e 's/psignal//'`"
#
for File in [Source + "/libiberty/configure", Source + "/libiberty/configure.ac"]:
    ChangeLineInFile("      checkfuncs=\"`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`\"\n",
                     "      checkfuncs=\"`echo $checkfuncs | sed -e 's/psignal//'`\"\n",
                     File)

#
# But no! That is all just dead code.
# config.log jumps from
# configure:4938: checking for pid_t
# ..
# configure:4992: result: yes
# to
# configure:8538: checking for stdlib.h
#
# It is all skipped because
# configure.ac:362: if test "x" = "y"; then
# configure:5068: if test "x" = "y"; then
#
# Uh, no. Because of this line:
#
# configure.ac 511 or 570?: if test -z "${setobjs}"; then
# configure:6027 or 6165?
#
# $checkfuncs is dead. $funcs is alive.
# This change should perhaps be conditionalized on platform being cygwin.
# But autoconf just works, right?
#
    #AddLineAfterLine("funcs=\"$funcs waitpid\"\n",
    #                 "funcs=\"$funcs strsignal\"\n",
    #                 File)

#
# Forget it, just do this:
#
AddLineAfterLine("#define HAVE_SYS_NERR 1\n",
                 "#ifdef __CYGWIN__\n#define HAVE_STRSIGNAL 1\n#endif\n",
                 Source + "/libiberty/configure")

AddLineAfterLine("AC_DEFINE(HAVE_SYS_NERR)\n",
                 "AC_DEFINE(HAVE_STRSIGNAL)\n",
                 Source + "/libiberty/configure.ac")
#
# NOTE this isn't what rebuilding from configure.ac will get you, but
# it is close enough. There are two occurences of #define HAVE_SYS_NERR 1,
# one is in the dead code, like 5675, guarded by if x = y. really this time,
# followed by HAVE_SYS_SIGLIST. The other is in a Cygwin-specific lump,
# line 6021, not dead, and what we want to hit (it also applies to mingwin;
# will that hurt us? We'll find out much later. Yes, it appears likely.
# Therefore the #ifdef __CYGWIN__, or #ifndef __MINGW32__.)
# So the right fix to configure.ac will include breaking up the switch on platform.
#


 - Jay






> From: jay.krell@cornell.edu
> To: angelo.graziosi@alice.it; fortran@gcc.gnu.org
> CC: aaronavay62@aaronwl.com
> Subject: RE: old but current libiberty/strsignal vs. cygwin
> Date: Sun, 14 Sep 2008 13:15:51 +0000
>
>
> Thanks.
> I need to get back to this.
> I have a workaround for now. Equiv I think to the #ifdef __CYGWIN__
> in one of those threads.
>
> I am maintaining a bunch of local patches and hope to someday get them accepted.
> I had trouble building autogen, which is needed to properly patch some things.
> For example, the host vs. target mixups in the winsup directory -- try
> building -host i686-pc-cygwin -target i686-pc-mingw32; it goes and tries
> to build the cygwin/utils and cygwin/server, under the winsup directory.
>
> The configure comment one of those mails refers to is wrong.
> Cygwin stopped getting its strsignal from libiberty years ago.
>
> However I'm not sure that code even runs.
> Large swaths of configure get skipped.
> I have to go check the comments in my patch.
>
> I have to poke around here additionally to get rid of the "auto import of data" warnings.
>
> Thanks.
>
> Later,
> - Jay
>
>
>> Date: Sun, 14 Sep 2008 10:08:22 +0200
>> From: angelo.graziosi@alice.it
>> To: fortran@gcc.gnu.org
>> CC: aaronavay62@aaronwl.com; jay.krell@cornell.edu
>> Subject: Re: old but current libiberty/strsignal vs. cygwin
>>
>> Aaron W. LaFramboise wrote:
>>
>>>> Nobody builds gcc + cygwin in an integrated tree?
>>>> I wish I could integrate more into The One Tree.
>>>> I so dislike everything being separate..
>>>
>>> Probably not, especially because relatively few people are doing their
>>> own Cygwin builds at all.
>>
>>
>> I build gfortran weekly on Cygwin! and flagged this problem on June.
>>
>> This thread [1] should explain many things, mainly why this problem happens.
>>
>>
>> Cheers,
>> Angelo.
>>
>> ---
>> [1]
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00666.html
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00674.html
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00678.html
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00680.html
>> http://gcc.gnu.org/ml/gcc/2008-06/msg00681.html
>> http://gcc.gnu.org/ml/gcc/2008-07/msg00197.html
>> http://gcc.gnu.org/ml/gcc/2008-07/msg00228.html
>>
>>
>>
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: build.py
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20080914/54ab755d/attachment.ksh>

More information about the Fortran mailing list