From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13133 invoked by alias); 26 Mar 2006 08:15:34 -0000 Received: (qmail 13125 invoked by uid 22791); 26 Mar 2006 08:15:33 -0000 X-Spam-Check-By: sourceware.org Received: from ip127.bb146.pacific.net.hk (HELO mailhub.stlglobal.com) (202.64.146.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 26 Mar 2006 08:15:33 +0000 Received: from localhost ([127.0.0.1]) by mailhub.stlglobal.com with esmtp (Exim 4.50) id 1FNQPB-00072q-Cd for gdb-patches@sources.redhat.com; Sun, 26 Mar 2006 16:15:21 +0800 Message-ID: <44264D9D.5070305@tausq.org> Date: Sun, 26 Mar 2006 10:16:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [patch] Compile fix for 64-bit HPUX Content-Type: multipart/mixed; boundary="------------020107010909050409060506" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00299.txt.bz2 This is a multi-part message in MIME format. --------------020107010909050409060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 880 On 64-bit HPUX, gdb fails to compile with -Werror because of an incorrect iconv() prototype. gdb's configure script checks for this, but because the configure script test is compiled without -Werror even when -Werror is enabled, the test doesn't detect the condition properly. The attached patch forces this test to use the value of WERROR_CFLAGS so that the check uses the same flags that will be used to build gdb. tbh I think this is really a hack and we should somehow make all the autoconf test use the -Werror flag when running the compile tests, but it's not obvious to me how I can do this without redoing a lot of the Makefile logic (for example, why do we use a separate WERROR_CFLAGS and not just append the -Werror into CFLAGS?)... Anyway, is this ok? Tested on hppa64-hp-hpux11.11; may also help other archs that need ICONV_CONST to be defined. randolph --------------020107010909050409060506 Content-Type: text/x-patch; name="hp64comp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hp64comp.diff" Content-length: 1096 2006-03-26 Randolph Chung * acinclude.m4 (ICONV_CONST): Compile test with -Werror if enabled. Index: acinclude.m4 =================================================================== RCS file: /cvs/src/src/gdb/acinclude.m4,v retrieving revision 1.13 diff -u -p -r1.13 acinclude.m4 --- acinclude.m4 17 Dec 2005 22:33:59 -0000 1.13 +++ acinclude.m4 26 Mar 2006 08:07:55 -0000 @@ -892,6 +892,8 @@ AC_DEFUN([AM_ICONV], if test "$am_cv_func_iconv" = yes; then AC_DEFINE(HAVE_ICONV, 1, [Define if you have the iconv() function.]) AC_MSG_CHECKING([for iconv declaration]) + oldcflags="${CFLAGS-}" + CFLAGS="${CFLAGS-} $WERROR_CFLAGS" AC_CACHE_VAL(am_cv_proto_iconv, [ AC_TRY_COMPILE([ #include @@ -910,6 +912,7 @@ size_t iconv(); am_cv_proto_iconv=`echo "[$]am_cv_proto_iconv" | tr -s ' ' | sed -e 's/( /(/'` AC_MSG_RESULT([$]{ac_t:- }[$]am_cv_proto_iconv) + CFLAGS=$oldcflags AC_DEFINE_UNQUOTED(ICONV_CONST, $am_cv_proto_iconv_arg1, [Define as const if the declaration of iconv() needs const.]) fi --------------020107010909050409060506--