Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <3B7B3940.4090007@ece.gatech.edu> Date: Wed, 15 Aug 2001 23:08:48 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: Charles Wilson CC: cygwin-developers AT cygwin DOT com Subject: Re: Does CVS build? References: <20010815132450 DOT A1468 AT dothill DOT com> <3B7AEC05 DOT 7FBF0C8C AT yahoo DOT com> <20010815155157 DOT B20199 AT redhat DOT com> <20010815162916 DOT A28118 AT redhat DOT com> <20010815171031 DOT A29030 AT redhat DOT com> <3B7AE8D7 DOT 7050508 AT ece DOT gatech DOT edu> <3B7AFEF9 DOT 8070400 AT ece DOT gatech DOT edu> <3B7B2581 DOT 9090904 AT ece DOT gatech DOT edu> <3B7B27C4 DOT 9000506 AT ece DOT gatech DOT edu> Content-Type: multipart/mixed; boundary="------------020502000805050305070701" This is a multi-part message in MIME format. --------------020502000805050305070701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Okay, with the attached patch (which includes Chris' change, but does NOT include the modifications to "libiberty/configure" which autconf did: I was able to build cygiwn dll from source. Yay. this attached patch differs from the one I posted a few hours ago only in that it includes the correction that I pointed out minutes later. Better, I then tested a "pristine" automake-1.4l build and was able to pass the three tests (lex3, pr9, and pr87) which had been failing. (because those three tests called 'make distcheck', which does the 'cp -p' thing, yadda yadda). The point: Corinna's utime() fix corrects this problem. On NTFS. With ntsec. --Chuck --------------020502000805050305070701 Content-Type: text/plain; name="libiberty.patchB" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libiberty.patchB" Index: aclocal.m4 =================================================================== RCS file: /cvs/src/src/libiberty/aclocal.m4,v retrieving revision 1.4 diff -u -r1.4 aclocal.m4 --- aclocal.m4 2001/03/06 18:27:14 1.4 +++ aclocal.m4 2001/08/16 02:59:28 @@ -1,3 +1,33 @@ +dnl forward compatibility macros: make autoconf 2.13 look like 2.50 +ifdef([AC_PROG_CC_WORKS], + [define([MY_CC_WORKS],[AC_PROG_CC_WORKS])dnl +define([MY_CC_GNU],[AC_PROG_CC_GNU])dnl +define([MY_CXX_WORKS],[AC_PROG_CXX_WORKS])dnl +define([MY_CXX_GNU],[AC_PROG_CXX_GNU])dnl +], + [define([MY_CC_WORKS], + [AC_LANG_PUSH(C)dnl +_AC_COMPILER_EXEEXT +_AC_COMPILER_OBJEXT +AC_LANG_POP()])dnl +define([MY_CC_GNU], + [AC_LANG_PUSH(C)dnl +_AC_LANG_COMPILER_GNU +AC_LANG_POP()])dnl +define([MY_CXX_WORKS], + [AC_LANG_PUSH(C++)dnl +_AC_COMPILER_EXEEXT +_AC_COMPILER_OBJEXT +AC_LANG_POP()])dnl +define([MY_CXX_GNU], + [AC_LANG_PUSH(C++)dnl +_AC_LANG_COMPILER_GNU +AC_LANG_POP()])dnl +]) +ifdef([_AC_PROG_CC_G],[], + [AC_DEFUN([_AC_PROG_CC_G],[AC_PROG_CC_G])]) +ifdef([_AC_PROG_CXX_G],[], + [AC_DEFUN([_AC_PROG_CCX_G],[AC_PROG_CCX_G])]) dnl See whether strncmp reads past the end of its string parameters. dnl On some versions of SunOS4 at least, strncmp reads a word at a time dnl but erroneously reads past the end of strings. This can cause @@ -99,7 +129,7 @@ test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH]) fi -AC_PROG_CC_GNU +MY_CC_GNU if test $ac_cv_prog_gcc = yes; then GCC=yes @@ -110,7 +140,7 @@ ac_test_CFLAGS="${CFLAGS+set}" ac_save_CFLAGS="$CFLAGS" CFLAGS= - AC_PROG_CC_G + _AC_PROG_CC_G if test "$ac_test_CFLAGS" = set; then CFLAGS="$ac_save_CFLAGS" elif test $ac_cv_prog_cc_g = yes; then Index: configure.in =================================================================== RCS file: /cvs/src/src/libiberty/configure.in,v retrieving revision 1.13 diff -u -r1.13 configure.in --- configure.in 2001/07/05 17:29:17 1.13 +++ configure.in 2001/08/16 02:59:34 @@ -177,8 +177,10 @@ # Of the functions in $checkfuncs, newlib only has strerror. AC_DEFINE_NOAUTOHEADER(HAVE_STRERROR) - setobjs=yes - + case "$host" in + *-*-cygwin*) ;; + *) setobjs=yes ;; + esac fi else @@ -221,13 +223,6 @@ setobjs=yes ;; - esac -fi - -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 @@ -247,6 +242,31 @@ funcs="`echo $funcs | sed -e 's/random//'`" LIBOBJS="$LIBOBJS random.o" vars="`echo $vars | sed -e 's/sys_siglist//'`" + # Newer cygwins define sys_errlist and sys_nerr. + # We have a chicken/egg situation here, though. How do we know that + # the toolchain being built contains a newer cygwin? + # The code below checks for the existence of sys_errlist in the + # winsup/cygwin/cygwin.din file. The assumption is that you are going + # to be building a dll which contains this global. + # If this is not found then check if the export is in the library + # that is used by GCC. Define the appropriate libiberty_cv_var variables + # if so. + if test -z "$libiberty_cv_var_sys_errlist" + then + eval `sed -n -e 's/^sys_errlist.*/libiberty_cv_var_sys_errlist=yes/p' \ + -e 's/^sys_nerr .*/libiberty_cv_var_sys_nerr=yes/p' \ + "$srcdir/../winsup/cygwin/cygwin.din" 2>/dev/null` + if test -z "$libiberty_cv_var_sys_errlist" + then + for v in sys_errlist sys_nerr; do + AC_TRY_LINK([int *p;], [extern int _imp__$v; p = &_imp__$v;], + [eval "libiberty_cv_var_$v=yes"], + [eval "libiberty_cv_var_$v=no"]) + done + fi + fi + test -z "$libiberty_cv_var_sys_errlist" && libiberty_cv_var_sys_errlist=no + test -z "$libiberty_cv_var_sys_nerr" && libiberty_cv_var_sys_nerr=no checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`" fi ;; @@ -274,7 +294,7 @@ # We haven't set the list of objects yet. Use the standard autoconf # tests. This will only work if the compiler works. - AC_PROG_CC_WORKS + MY_CC_WORKS AC_REPLACE_FUNCS($funcs) libiberty_AC_FUNC_C_ALLOCA AC_FUNC_VFORK --------------020502000805050305070701--