Mail Archives: cygwin-developers/2001/08/17/19:07:24
This is a multi-part message in MIME format.
--------------050901060207090307060701
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
> After some back and forth discussion, I have checked in a fix for
> the libiberty problem that was raised here earlier.
>
> It bears no resemblance to my previous change. It is *a lot* simpler,
> actually.
>
> So, CVS should build again.
FWIW, libiberty/configure.in still isn't autoconf-able with 2.52, unless
something is done; the attached patch has the following characteristics:
1) using autoconf-2.13, winsup updated from cvs (includes cgf's most
recent change to libiberty), and the attached patch: autoconf-2.13 in
libiberty generates a configure that is identical to the one Chris put
into CVS earlier today.
(Yes, since everybody ignored my patch, I re-installed the obsolete
autoconf-2.13 package and tested the damn thing myself.)
2) using autoconf-2.52, (all other things the same as in #1), autoconf
generates a "working"(*) configure in libiberty.
(*) It runs and generates a decent Makefile; stderr messages from
configure look as expected, but...
In both cases, I still can't build a working cygwin: "conflicting types
for `sys_errlist'" etc.
WITHOUT my patch, autoconf-2.52 fails. 2.13 works, of course -- but I
still can't build cygwin.
e.g. we have two "problems"
a) Chris's new fix doesn't fix the "CVS cygwin doesn't build" problem
b) at least in the libiberty directory, autoconf-2.52 doesn't work.
My patch addresses b), not a).
--Chuck
--------------050901060207090307060701
Content-Type: text/plain;
name="libiberty.patchC"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="libiberty.patchC"
Index: libiberty/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/17 22:47:45
@@ -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: libiberty/configure.in
===================================================================
RCS file: /cvs/src/src/libiberty/configure.in,v
retrieving revision 1.14
diff -u -r1.14 configure.in
--- configure.in 2001/08/17 21:14:20 1.14
+++ configure.in 2001/08/17 22:47:50
@@ -280,7 +280,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
--------------050901060207090307060701--
- Raw text -