This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/613: Obsolete m68*-apollo*-bsd*
- From: ac131313 at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 25 Jul 2002 22:47:50 -0000
- Subject: gdb/613: Obsolete m68*-apollo*-bsd*
- Reply-to: ac131313 at redhat dot com
>Number: 613
>Category: gdb
>Synopsis: Obsolete m68*-apollo*-bsd*
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Thu Jul 25 15:48:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
Daniel J writes:
On Sun, May 12, 2002 at 11:46:02PM -0400, Andrew Cagney wrote:
> >On Sun, May 12, 2002 at 12:47:48AM -0400, Daniel Jacobowitz wrote:
> >
> >>I was going through some cleanups to 'struct type' this evening and
> >>noticed
> >>more abuse of copying types in dstread.c and hpread.c. dstread.c is only
> >>used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
> >>perhaps we should do the same for the next cycle?
> >>
> >>hpread, unfortunately, I don't think I can dismiss that easily :( Guess
> >>I'll have to fix it; it has similar problems to stabs with regard to
> >>replacing incomplete types.
> >
> >
> >Corollary to this: dstread.c has not been compiled successfully since
> >at least 1995, when function_type was removed from struct type. I
> >don't want to be the one to fix it :)
>
> os9kread.c has already been bug reported for obsolecence.
>
> If nothing else bug report these. Hmm, lets just obsolete the entire
> apollo line ...
Found this in the mailbox... since no one else commented, I'd like to
propose that we obsolete m68*-apollo*-bsd*. I haven't seen even a
reference to it in years.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: