gdb/613: Obsolete m68*-apollo*-bsd*

[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: