5.1 ERRATA file?

5.1 ERRATA file?

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

Hello,

Something I noticed from the feedback so far is that it is hard to know 
what problems a release will have - they are burried in the file 
gdb/README.  What do people think of them being moved to the file 
gdb/ERRATA?  Then again, the GNU coding standard might override such an 
idea :-/

(This is more of a policy decision so I've posted it to gdb@ rather than 
gdb-patches@)

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3749 bytes --]

2001-11-27  Andrew Cagney  <ac131313@redhat.com>

	* ERRATA: New file.  Move build notes to here.
	* README: From here.

Index: ERRATA
===================================================================
RCS file: ERRATA
diff -N ERRATA
*** /dev/null	Tue May  5 13:32:27 1998
--- ERRATA	Mon Nov 26 22:51:37 2001
***************
*** 0 ****
--- 1,45 ----
+ hppa2.0-hp-hpux10.20
+ 
+ Due to a problem (conflicting types) with libiberty/regex.c, GDB 5.1
+ does not build on HP/UX 10.20 when using the HP supplied compiler.
+ 
+ Due to bit rot, GDB 5.1 does not work on HP/UX 10.20 when built with
+ GCC.
+ 
+ 
+ hppa2.0w-hp-hpux11.00
+ 
+ Due to a problem with ltconfig and long argument lines, GDB 5.1 does
+ not configure on HP/UX 11.00.
+ 
+ 
+ alpha-dec-osf5.1
+ 
+ GDB 5.1 has a number of problems on this platform (Ref PR gdb/237).  A
+ GDB 5.1 built with ``CC="cc -DUSE_LDR_ROUTINES"'' is reported to work
+ much better.
+ 
+ 
+ alpha-dec-osf4.0e
+ 
+ GDB 5.1 is known to have problems on this platform (encounters an
+ internal error in the symbol table reader).
+ 
+ 
+ sparcv9-sun-solaris2.8
+ 
+ There are known problems with building GDB 5.1 using GCC 3.0.x for the
+ 64 bit SPARC target (bad code gen).  You could try a development
+ version of GCC.
+ 
+ 
+ i586-sco-sysv5uw7.1.1
+ 
+ There are known problems with GDB 5.1's thread support on this
+ platform.  Non-threaded programs should work.
+ 
+ 
+ *-*-*
+ 
+ GDB 5.1 assumes that the host C compiler implemends alloca().  GCC is
+ one such compiler.  This problem should be fixed on the trunk.
Index: README
===================================================================
RCS file: /cvs/src/src/gdb/README,v
retrieving revision 1.8.2.5
diff -p -r1.8.2.5 README
*** README	2001/11/18 04:42:41	1.8.2.5
--- README	2001/11/27 06:52:02
*************** A summary of new features is in the file
*** 7,13 ****
--- 7,15 ----
  See the GDB home page at http://www.gnu.org/software/gdb/ for up to
  date release information, mailing list links and archives, etc.
  
+ See the file ERRATA for late breaking news.
  
+ 
  Unpacking and Installation -- quick overview
  ==========================
  
*************** prefer; but you may abbreviate option na
*** 425,480 ****
  `configure' accepts other options, for compatibility with configuring
  other GNU tools recursively; but these are the only options that affect
  GDB or its supporting libraries.
- 
- 
- Host/target specific installation notes
- =======================================
- 
- hppa2.0-hp-hpux10.20
- 
- Due to a problem (conflicting types) with libiberty/regex.c, GDB 5.1
- does not build on HP/UX 10.20 when using the HP supplied compiler.
- 
- Due to bit rot, GDB 5.1 does not work on HP/UX 10.20 when built with
- GCC.
- 
- 
- hppa2.0w-hp-hpux11.00
- 
- Due to a problem with ltconfig and long argument lines, GDB 5.1 does
- not configure on HP/UX 11.00.
- 
- 
- alpha-dec-osf5.1
- 
- GDB 5.1 has a number of problems on this platform (Ref PR gdb/237).  A
- GDB 5.1 built with ``CC="cc -DUSE_LDR_ROUTINES"'' is reported to work
- much better.
- 
- 
- alpha-dec-osf4.0e
- 
- GDB 5.1 is known to have problems on this platform (encounters an
- internal error in the symbol table reader).
- 
- 
- sparcv9-sun-solaris2.8
- 
- There are known problems with building GDB 5.1 using GCC 3.0.x for the
- 64 bit SPARC target (bad code gen).  You could try a development
- version of GCC.
- 
- 
- i586-sco-sysv5uw7.1.1
- 
- There are known problems with GDB 5.1's thread support on this
- platform.  Non-threaded programs should work.
- 
- 
- *-*-*
- 
- GDB 5.1 assumes that the host C compiler implemends alloca().  GCC is
- one such compiler.  This problem should be fixed on the trunk.
  
  
  Remote debugging
--- 427,432 ----

Re: 5.1 ERRATA file?

[Eli Zaretskii]

On Tue, 27 Nov 2001, Andrew Cagney wrote:

> Something I noticed from the feedback so far is that it is hard to know 
> what problems a release will have - they are burried in the file 
> gdb/README.  What do people think of them being moved to the file 
> gdb/ERRATA?

I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.

Re: 5.1 ERRATA file?

[gdb]

On Tue, Nov 27, 2001 at 09:41:03AM +0200, Eli Zaretskii wrote:
> 
> On Tue, 27 Nov 2001, Andrew Cagney wrote:
> 
> > Something I noticed from the feedback so far is that it is hard to know 
> > what problems a release will have - they are burried in the file 
> > gdb/README.  What do people think of them being moved to the file 
> > gdb/ERRATA?
> 
> I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.

Emacs has PROBLEMS.

-- 
albert chin (china@thewrittenword.com)

Re: 5.1 ERRATA file?

[David Relson]

At 02:00 AM 11/27/01, Andrew Cagney wrote:

>Something I noticed from the feedback so far is that it is hard to know 
>what problems a release will have - they are burried in the file 
>gdb/README.  What do people think of them being moved to the file 
>gdb/ERRATA?  Then again, the GNU coding standard might override such an 
>idea :-/

Andrew,

I like the idea.  The name ERRATA is clear and, as with all files with 
all-caps in their names, it stands out in a directory listing.

David

Re: 5.1 ERRATA file?

[Andrew Cagney]

> On Tue, Nov 27, 2001 at 09:41:03AM +0200, Eli Zaretskii wrote:
> 
>> 
>> On Tue, 27 Nov 2001, Andrew Cagney wrote:
>> 
> 
>> > Something I noticed from the feedback so far is that it is hard to know 
>> > what problems a release will have - they are burried in the file 
>> > gdb/README.  What do people think of them being moved to the file 
>> > gdb/ERRATA?
> 
>> 
>> I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.
> 
> 
> Emacs has PROBLEMS.

Hmm, while I prefer ERRATA, I'm never one to pass up an oportunity that 
lets me use EMACS as the rationale for a decision.  -> PROBLEMS (ulgh).

Again?

I think BUGS would be confusing.  A problem might be caused by several 
bugs -> HP/UX.

	Andrew

5.1 ERRATA file?

[Andrew Cagney]

Hello,

Something I noticed from the feedback so far is that it is hard to know 
what problems a release will have - they are burried in the file 
gdb/README.  What do people think of them being moved to the file 
gdb/ERRATA?  Then again, the GNU coding standard might override such an 
idea :-/

(This is more of a policy decision so I've posted it to gdb@ rather than 
gdb-patches@)

Andrew
From ac131313@cygnus.com Mon Nov 26 23:24:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sources.redhat.com
Subject: 5.1.1 commit policy
Date: Mon, 26 Nov 2001 23:24:00 -0000
Message-id: <3C033F9C.8070001@cygnus.com>
X-SW-Source: 2001-11/msg00277.html
Content-length: 1087

Same rules as for 5.1 apply :-)

http://sources.redhat.com/ml/gdb/2001-07/msg00418.html
> There, er, is no 5.1 branch commit policy.  Instead the MAINTAINERS file 
> still holds.
> 
> The only things I ask are:
> 
> o 
> don't fix something on the branch
> 	unless/until it is also fixed in
> 	the trunk.  If this isn't possible
> 	then I think a mention in the
> 	gdb/README file is better.
> 
> o 
> try criteria like:
> 	- does it fix a build build
> 	- does does it fix break main,
> 	  run on a static binary
> 
> o 
> only propose changes to core-gdb
> 	after you've sent individual
> 	bribes to all the people listed
> 	in the MAINTAINERS file :-)
> 
> o 
> the further you are away from
> 	core-gdb then the less likely
> 	that it will worry me (i.e. target
> 	specific code).
> 
> enjoy,
> 	Andrew
> 
> 


looks like some fixes for HP/UX at least will be available.  That top 
level tweek, for instance, can probably be put onto the branch.

	Andrew

PS: If you need to send a bribe, I've organied a credit card facility - 
dial +1 555 123 4567 and just follow the prompts ;-)

Re: 5.1 ERRATA file?

[Eli Zaretskii]

On Tue, 27 Nov 2001, Andrew Cagney wrote:

> Something I noticed from the feedback so far is that it is hard to know 
> what problems a release will have - they are burried in the file 
> gdb/README.  What do people think of them being moved to the file 
> gdb/ERRATA?

I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.

Re: 5.1 ERRATA file?

[gdb]

On Tue, Nov 27, 2001 at 09:41:03AM +0200, Eli Zaretskii wrote:
> 
> On Tue, 27 Nov 2001, Andrew Cagney wrote:
> 
> > Something I noticed from the feedback so far is that it is hard to know 
> > what problems a release will have - they are burried in the file 
> > gdb/README.  What do people think of them being moved to the file 
> > gdb/ERRATA?
> 
> I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.

Emacs has PROBLEMS.

-- 
albert chin (china@thewrittenword.com)

Re: 5.1 ERRATA file?

[David Relson]

At 02:00 AM 11/27/01, Andrew Cagney wrote:

>Something I noticed from the feedback so far is that it is hard to know 
>what problems a release will have - they are burried in the file 
>gdb/README.  What do people think of them being moved to the file 
>gdb/ERRATA?  Then again, the GNU coding standard might override such an 
>idea :-/

Andrew,

I like the idea.  The name ERRATA is clear and, as with all files with 
all-caps in their names, it stands out in a directory listing.

David

Re: 5.1 ERRATA file?

[Andrew Cagney]

> On Tue, Nov 27, 2001 at 09:41:03AM +0200, Eli Zaretskii wrote:
> 
>> 
>> On Tue, 27 Nov 2001, Andrew Cagney wrote:
>> 
> 
>> > Something I noticed from the feedback so far is that it is hard to know 
>> > what problems a release will have - they are burried in the file 
>> > gdb/README.  What do people think of them being moved to the file 
>> > gdb/ERRATA?
> 
>> 
>> I suggest gdb/PROBLEMS or even (gasp) gdb/BUGS.
> 
> 
> Emacs has PROBLEMS.

Hmm, while I prefer ERRATA, I'm never one to pass up an oportunity that 
lets me use EMACS as the rationale for a decision.  -> PROBLEMS (ulgh).

Again?

I think BUGS would be confusing.  A problem might be caused by several 
bugs -> HP/UX.

	Andrew