From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11107 invoked by alias); 15 May 2005 21:58:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11079 invoked from network); 15 May 2005 21:58:41 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 15 May 2005 21:58:41 -0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j4FLwdeJ006346; Sun, 15 May 2005 23:58:39 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j4FLwcSL017719; Sun, 15 May 2005 23:58:38 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j4FLwYhY001085; Sun, 15 May 2005 23:58:34 +0200 (CEST) Date: Sun, 15 May 2005 21:58:00 -0000 Message-Id: <200505152158.j4FLwYhY001085@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: dev@keyslapper.net CC: gdb@sources.redhat.com In-reply-to: <20050513201001.GE42535@keyslapper.net> (message from Louis LeBlanc on Fri, 13 May 2005 16:10:01 -0400) Subject: Re: gdb 6.3 build fails on Solaris References: <20050513201001.GE42535@keyslapper.net> X-SW-Source: 2005-05/txt/msg00156.txt.bz2 Date: Fri, 13 May 2005 16:10:01 -0400 From: Louis LeBlanc Hey folks. I'm new on this particular list, but I have tried searching the archives (and Google) for any solution to my problem. I've tried building gdb 6.3 on several versions of Solaris, both Intel and Sparc architectures, and have yet to see it build completely. Uh yeah, gdb 6.3 was a bit goofed on SPARC. On Solaris 8 Sparc, the failure is as follows: . . . gcc -c -g -O2 -I. -I../../gdb -I../../gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../../gdb/../readline/.. -I../bfd -I../../gdb/../bfd -I../../gdb/../include -I../intl -I../../gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/procfs.c In file included from ../../gdb/procfs.c:37: /usr/include/sys/procfs.h:153: error: parse error before "taskid_t" /usr/include/sys/procfs.h:157: error: parse error before '}' token /usr/include/sys/procfs.h:269: error: parse error before "taskid_t" /usr/include/sys/procfs.h:271: error: conflicting types for `pr_filler' /usr/include/sys/procfs.h:155: error: previous declaration of `pr_filler' /usr/include/sys/procfs.h:272: error: conflicting types for `pr_lwp' /usr/include/sys/procfs.h:156: error: previous declaration of `pr_lwp' /usr/include/sys/procfs.h:273: error: parse error before '}' token ../../gdb/procfs.c:329: error: parse error before "gdb_prstatus_t" ../../gdb/procfs.c:329: warning: type defaults to `int' in declaration of `gdb_prstatus_t' ../../gdb/procfs.c:329: warning: data definition has no type or storage class I've never seen this failure. I've been building gdb on SPARC Solaris 2.6, 7 and 9 from time to time and I can't remember ever seeing this particular failure. Could you try building a recent gdb snapshot on your system. See http://sourceware.org/gdb on how to obtain a snapshot. It's slightly different on Solaris 10 Intel: . . . gcc -c -g -O2 -I. -I../../gdb -I../../gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../../gdb/../readline/.. -I../bfd -I../../gdb/../bfd -I../../gdb/../include -I../intl -I../../gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/tui/tui.c In file included from ../../gdb/tui/tui.c:48: /usr/include/term.h:1060: error: parse error before "SGTTY" /usr/include/term.h:1120: error: parse error before '}' token Ah, this defenitely has been fixed a while ago. Mark