From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sources.redhat.com
Subject: 5.1 ERRATA file?
Date: Fri, 16 Nov 2001 07:37:00 -0000 [thread overview]
Message-ID: <3C033A28.50209@cygnus.com> (raw)
[-- 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 ----
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sources.redhat.com
Subject: 5.1 ERRATA file?
Date: Mon, 26 Nov 2001 23:01:00 -0000 [thread overview]
Message-ID: <3C033A28.50209@cygnus.com> (raw)
Message-ID: <20011126230100.1QoxjQPiDGSAbLqCnG_C40f2qoz0s0aLY9oRq1IYbWg@z> (raw)
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 ;-)
next reply other threads:[~2001-11-27 7:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 7:37 Andrew Cagney [this message]
2001-11-16 9:42 ` Eli Zaretskii
2001-11-26 23:41 ` Eli Zaretskii
2001-11-27 5:03 ` gdb
2001-11-17 8:54 ` gdb
2001-11-19 3:12 ` Andrew Cagney
2001-11-27 23:15 ` Andrew Cagney
2001-11-17 10:40 ` David Relson
2001-11-27 6:47 ` David Relson
2001-11-26 23:01 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C033A28.50209@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox