From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23872 invoked by alias); 1 Mar 2006 15:23:06 -0000 Received: (qmail 23863 invoked by uid 22791); 1 Mar 2006 15:23:06 -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; Wed, 01 Mar 2006 15:23:05 +0000 Received: from localhost ([127.0.0.1]) by mailhub.stlglobal.com with esmtp (Exim 4.50) id 1FETAA-0006HT-8A for gdb@sources.redhat.com; Wed, 01 Mar 2006 23:22:50 +0800 Message-ID: <4405BC50.3070603@tausq.org> Date: Wed, 01 Mar 2006 15:23:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: hpux build errors, and -Werror Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00005.txt.bz2 Currently on hppa64-hp-hpux11.11, gdb fails to build with -Werror because we are not getting the const flag correct with iconv() calls. gdb's configure script actually has some tests for this, from acinclude.m4, however, the test doesn't actually work (at least in this case), because configure doesn't compile the test program with -Werror, and the resultant warning doesn't trigger the script to define ICONV_CONST I'm not very good with autoconf & friends and can't figure out the right way to fix it. Can somebody give me some hints? On hppa2.0w-hp-hpux11.11, there is a different problem, at least on the system I'm testing on: ser-tcp.c:209 has a call to getsockopt. This causes a (fatal) warning: ../../gdb/gdb/ser-tcp.c:209: warning: passing arg 5 of `getsockopt' from incompatible pointer type getsockopt is declared as: extern int getsockopt (int, int, int, void *, int *); whereas socklen_t is: typedef long unsigned int size_t typedef size_t socklen_t; I would argue the headers are broken on this platform, but nonetheless we may need to find a way to workaround this in gdb. I can't think of any good way to do this though. Comments appreciated. randolph