HDTenEightyP/NetNews huggingface dataset:
From: sengillo@music.Kodak.COM (Alan Sengillo)
Subject: epoch under SCO Open Desktop
Reply-To: sengillo@Kodak.COM
Organization: Eastman Kodak Co., Rochester, NY
Date: Thu, 31 Dec 92 20:11:16 GMT

-- 

Has any tried porting epoch to run under SCO Open Desktop? I got it to compile,
but when I run it I get the following error:


Xlib:  sequence lost (0x16968 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x16143 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x10a30 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x13532 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x1440a > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x10a30 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x13c20 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x16461 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x13233 > 0x2) in reply type 0xa!
Xlib:  sequence lost (0x1654b > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x14b3c > 0x2) in reply type 0xa!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0xa!
Xlib:  sequence lost (0x16574 > 0x2) in reply type 0xa!
Xlib:  sequence lost (0x12253 > 0x2) in reply type 0x22!
Xlib:  sequence lost (0x12020 > 0x2) in reply type 0x20!
Xlib:  sequence lost (0x13078 > 0x2) in reply type 0x22!
Xlib:  sequence lost (0x16274 > 0x2) in reply type 0x9!
Xlib:  sequence lost (0x12054 > 0x2) in reply type 0x9!


If I do a Ctrl-C and try again, I get this error:

Xlib:  warning, client built for newer rev (11) than server (0)!
Xlib:  warning, client is protocol rev 0, server is rev 14848!


I am sending the display to a SUN IPC. If I try to run it on the SCO machine, I
just keep getting the "Xlib:  sequence lost..." errors.

	Alan Sengillo

	sengillo@Kodak.COM		Eastman Kodak Compnay
					901 ElmGrove Road
	(716) 726-9716			Rochester, New York 14653-5108
Newsgroups: gnu.epoch.misc
From: girod@kilohp.kiloapo.ts.tele.nokia.fi (Marc Girod)
Subject: key-bindings for epoch
Reply-To: marc.girod@ntc.nokia.com
Organization: /user/girod/.organization
Date: Thu, 31 Dec 1992 09:31:29 GMT

Hi netters!

Sorry for this typical FAQ...

I have been using emacs for about one year, and I'd like to switch to
epoch, at least while not connected through my home modem.

What I'd like now is a consistent set of keyboard definitions, for
creating screens with *most* of the new buffers; delete a screen with
the buffer it displays, in case there is only one; automatically name
the screens and the icons with the buffers; switch to the already open
screen where a given buffer is displayed...

These should be integrated with the various major modes: dired, gnus,
buffer menu, and so on...

At start, it feels to require a tremendous amount of work, if I want
to do this myself. But without that, I don't quite understand the
utility of epoch, so, I guess that there must be something like that
available... Am I right?

Happy New Year!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: gnu.epoch.misc
From: xcpslf@decsrv (stephen l favor)
Subject: Rectangular zones
Organization: Oryx Energy, Dallas, Texas.
X-Newsreader: Tin 1.1 PL4
Date: Tue, 22 Dec 1992 17:15:28 GMT

Is is possible to have a zone displayed as a rectangular area instead
of a contiguous piece of text?  For example, to implement rectangular
cut & paste.
From: shadagop@remus.rutgers.edu (Narayanan Shadagopan)
Newsgroups: gnu.epoch.misc
Subject: undo-infop in Epoch
Keywords: Epoch4.2 undo-infop void
Date: 24 Dec 92 00:06:55 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


When I cut and paste with Epoch 4.2, I get the following message:
Symbol's function definition is void: undo-infop. 

The debug stack is as follows:

  (void-function undo-infop)
  undo-infop()
  byte-code()
  mouse::paste-cut-buffer()
  funcall(mouse::paste-cut-buffer ())
  byte-code()
  event::handler()

I am using the Tek highlighting package. The whole problem is that there
is no .el file in my load-path that calls `undo-infop'. It is a function
that was defined in earlier versions of mouse.el (e.g. Epoch 3.2, which
also exists here, but files are not shared at all between 3.2 and 4.2).

Any idea what the problem might be?

-Nary
-- 
E-mail: shadagop@central.rutgers.edu
Newsgroups: gnu.epoch.misc
From: adij@di.ufpe.br (Alcino Dall Igna Junior)
Subject: Re: long messages in minibuffers
Reply-To: Alcino Dall Igna Junior <adij@di.ufpe.br>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 08:29:16 GMT

Sometimes I have the same problem with other long messages. The answers
from Mark Andreessen and Brook Conner manages just the *example* below and
not a general case. I had a very large minibuffer with 2 lines, but the
minibuffer didn't do wrap line, so sometimes I must guess what is the
message. There are some way to force the line wrap in the minibuffer?

Alcino Dall Igna Junior
Universidade Federal de Alagoas         alcino@ima.ufal.alan.br
Universidade Federal de Pernambuco      adij@di.ufpe.br


On 18 Dec 1992, Frank Caico wrote:

> Does anyone know of an elisp function, package or fix that will make
> viewing long minibuffer messages easier?
>
> Here is an example: I have about 6 or 7 directories in my load-path and I
From: dsg@blackbird.mitre.org (David S. Goldberg)
Newsgroups: gnu.epoch.misc
Subject: Strange key binding problem
Date: 24 Dec 92 19:22:21 GMT
Organization: The Mitre Corp., Bedford, MA.


I'm seeing a strange problem, and while I think I know what it is, I'm
asking for some confirmation.  I use tree-dired.  I've noticed that
some of the commands locally bound into the meta key map such as M-~
for dired-backup-diff, are no longer being bound to those keys.
Instead, if I do a where-is on those commands, the message comes up
with a blank for the bound character sequence (as opposed to telling
me it's not on any keys).  I suspect that this is because I complied
with a couple of user requests and compiled with EIGHTBIT_KEYBOARD
defined in config.h.  Is that the case?  If not, any ideas why it's
happening?

So far, as I run into these problems, I'm just explicitly binding them
in my mode hook.  Is there a better solution that I've missed in the
epoch documentation?  I didn't notice any mention of this behavior in
the FAQ or the INFO.

I don't think it matters, but this is happening on a MIPS running
RISCOS 4.52, an SGI running 4.0.5 and a Sun running 4.1.1.

Thanks,
--
Dave Goldberg                      UNIX Systems Programmer/Administrator
Post: The Mitre Corporation MS B020 202 Burlington Rd. Bedford, MA 01730
Phone: 617-271-2460
Domain: dsg@mbunix.mitre.org  UUCP: {your neighborhood}!linus!mbunix!dsg 
Newsgroups: gnu.epoch.misc
From: wolfgg@mistral.vta.mw.tu-muenchen.de (Wolfgang Goettert)
Subject: Infinite beep mode
Reply-To: wolfgg@urmel.vta.mw.tu-muenchen.de
Organization: LS Verfahrenstechnik A (Inst. Chem. Engng.), TU Muenchen, Germany
Date: Tue, 22 Dec 1992 09:14:12 GMT


Hi, 
from time to time I read about a bug in epoch which is referred to 
as 'Infinite beep mode': A message 'Marker does not point anywhere' is
displayed in the minibuffer, and the bell is rung forever. 

This bug happens quite often with Epoch 4.2.1 on a DECstation 
(Ultrix 4.2A and X11R5). I can stop this 'mode' only by killing Epoch.
My questions: What is the state of the discussion and is there a bug fix 
available?

Any help appreciated

Thanks
----------------------------------------------------------------------
| Wolfgang Goettert  Lehrstuhl A fuer Verfahrenstechnik, TU Muenchen |
|                    8000 Muenchen 2, Germany                        |
| wolfgg@urmel.vta.mw.tu-muenchen.de Tel.: +49 89 2105 2840          |
----------------------------------------------------------------------
From: etxmsll@eua.ericsson.se (Mats Lidell)
Newsgroups: gnu.epoch.misc
Subject: Key bindings with 8-bit mode
Date: 22 Dec 92 15:39:23 GMT
Distribution: gnu
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
X-Md4-Signature: f55c9d082b2fed1c12ae08ce1a10f73b
Comments: Hyperbole mail buttons accepted, v3.06.

Hi Folks,

I'm having the the following problem. 

I use/load a lot of different emacs-lisp packages (that works with
gnu-emacs.) Sometimes the package defines a local Meta-key-binding
like:

   (define-key major-mode-map "\M-k" 'do-something-in-this-mode)

Obviously I would like to keep this Meta-binding to the meta key but
apparently the function gets bound to some "interesting" 8-bit
character.

Is there some way to get this without having to change the define-key
statements in question.

Yours
%% Mats Lidell 
Newsgroups: gnu.epoch.misc
From: knabe@ECRC.DE (Fritz Knabe)
Subject: Unwanted recentering with other-window
Organization: European Computer-Industry Research Centre
Distribution: gnu
Date: Wed, 30 Dec 1992 09:56:55 GMT

Perhaps this has been reported already and is well-known, but...

In Epoch 4.2, when I do an other-window (which calls select-window), the
window I jump to is sometimes recentered. The behavior is very variable: it
appears to depend on where point is located in both the starting and
destination window. (All this is taking place in one screen.)

I looked at window.c, but nothing was immediately obvious. I have not
noticed this problem in the ascii Emacs which comes with Epoch.

Is there a fix?

Thanks,
Fritz
Newsgroups: gnu.epoch.misc
From: ddw2@sunbim.be (ddw for rubis at horizon)
Subject: Lightbrite.el and comments
Organization: BIM sa/nv, Everberg, Belgium
X-Newsreader: GNU Emacs 4.2.5, GNUS 3.13, NNTP 3.10
Date: Wed, 23 Dec 92 10:14:51 GMT


I have been looking at Marc's package and found it very nice. 
I would have loved if it had worked right away on prolog code where
there are (at least :-) 2 styles of comments:
         % up to eol
and      /*   */ 
(The problem should also appear in C++ I think).

As the code is, it only highlights the first line of a comment
starting with /*

In my attempt to find why, I looked at syntax-decode.el and
understood (or maybe I did not). The mechanism describing comments in
the syntax tables is not sufficient to provide an exact view of
comments when there are several possibilities.

What I think is needed is some way to determine what is the
end-of-comment-regexp given a start-of-comment-string that we found.
(or the reverse if scanning backwards). 

Has anyone worked on a more or less general solution to this problem?
I'd be interested in any pointer to a solution.


Thanks,

Dominique

--
==============================================
Dominique de Waleffe             ddw@sunbim.be
BIM sa
Kwikstraat 4			 Tel: +32 2 719 26 12
B-3078 Everberg			 Tel: +32 2 725 47 83
Belgium
From: adriaan@dcs.qmw.ac.uk (Adriaan Joubert)
Newsgroups: gnu.epoch.misc
Subject: Menus with xse on DEC with Ultrix 4.3
Date: 22 Dec 92 14:36:11 GMT
Organization: Computer Science Dept, QMW, University of London

Hi,

I have recently installed epoch on our DECstation 5000/240, and am trying
to persuade others to use epoch as well. The ideal way to ease the transition
seemed to be to add some menus.

The epoch FAQ explains how menus can be made using motif and a program called
xse (X send event). I managed to get the menus done, but on the DECstation
itself nothing happens....

If I use an old SUN 3/50, with only X running on the SUN and the window
manager mwm running on the DECstation, the menus work! Both systems are
definitely using exactly the same window manager and the same startup files.

So what's different on the DEC? The Version of X running on the Suns is
still X11R4 and on the DEC we've installed X11R5, but I would have thought
that these are backward compatible. 

If somebody has had this problem before, and knows how to fix it, please
send me a mail.

Oh, and if somebody knows how to get motif to put up menus anywhere in the
window with e.g. <Shift><Button1>, instead of only on the frame, I would
appreciate a hint!

Thanks,

Adriaan
--
-- 
 ***************************************************************************
 * Adriaan Joubert                * Janet       : adriaan@uk.ac.qmw.dcs    *
 * London Parallel 	          * Internet    : adriaan@dcs.qmw.ac.uk    *
 *           Applications Centre  *					   *
 * QMW University of London       * Fax         : +44-81-981 9803	   *
 * Mile End Road                  * Telephone   : +44-71-975 5168	   *
 * London E1 4NS                  *                                        *
 * United Kingdom                 *                                        *
 *************************************************************************** 
Newsgroups: gnu.epoch.misc
From: jct%se33@se01.wg2.waii.COM (Jim Thompson)
Subject: Unwanted recentering with other-window
Reply-To: thompson@wg2.waii.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 20:36:38 GMT

Fritz writes:
> Perhaps this has been reported already and is well-known, but...
> 
> In Epoch 4.2, when I do an other-window (which calls select-window), the
> window I jump to is sometimes recentered. The behavior is very variable: it
> appears to depend on where point is located in both the starting and
> destination window. (All this is taking place in one screen.)

I've noticed this too.  I haven't noticed anything about the behavior
depending on the point locations, though.  It seems to depend on the
size of the destination window; it usually occurs when the destination
window is small--less than 15 lines or so.

Jim
--
     _     Jim Thompson           |  Western Geophysical               __
   _| ~-   thompson@wg2.waii.com  |  Exploration Products             /\_\
   \,  _}  jimt@sugar.neosoft.com |  3600 Briarpark                   \/_/
     \(    (713) 964-6213         |  Houston, TX 77042






Newsgroups: gnu.bash.bug
From: p00185@psilink.com (Jeffrey W. Parker)
Subject: Compiling BASH 1.12 on an AIX370 machine
Organization: Performance Systems Int'l
Distribution: gnu
Date: Tue, 22 Dec 1992 16:39:24 GMT

Hello netters,
	I compiled BASH 1.12 on an IBM 370-type machine and it seemed
to compile just fine, but when I try to do virtually anything under the
shell I get the error "Illegal instruction" and it completely kills
my login.  Has anyone else seen this?  I'd appreciate any help.

Thanks,
Jeff Parker
p00185@psilink.com


Newsgroups: gnu.bash.bug
From: junio@twinsun.COM (Jun Hamano)
Subject: case bug
Organization: Twin Sun, Inc. (El Segundo CA)
Distribution: gnu
Date: Sat, 26 Dec 1992 06:28:52 GMT

Earlier I reported an incompatibility with pattern list in `case'
command.  Here is a fix.  A patch is attached to the end of this
message.

The problem::
	/bin/sh does not consider `abc' matches the pattern,
while bash 1.12 does, in the following script.

bash$ cat casebug.sh
__='
'
case abc in
*$__*) echo "The string abc has an newline in it." ;;
esac
bash$ 

The cause::
	When executing a case command, bash expands each pattern
in pattern lists and then splits it into word-lists.  In the
above example, *$__* is split into "*", and "*", because a
newline character resulting from $__ is part of $IFS.  Pattern
matching in execute_case_command is done with only the first word
of the list, in this case the first "*", which resulted in a
(false) match.  Bourne shell doesn't seem to split the result of
word expansion here.

The fix::
	In the patch attached below, I replaced a call to
expand_word() with expand_word_no_split().  This does the same
set of substitution as expand_word does, but the result of the
substitution is not split.

-- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 --

bash$ rcsdiff -u3 execute_cmd.c
===================================================================
RCS file: execute_cmd.c,v
retrieving revision 1.1
diff -u3 -r1.1 execute_cmd.c
--- execute_cmd.c	1992/12/26 05:45:08	1.1
+++ execute_cmd.c	1992/12/26 05:56:08
@@ -66,7 +66,7 @@
 extern pid_t last_made_pid;
 #endif
 
-extern WORD_LIST *expand_words (), *expand_word ();
+extern WORD_LIST *expand_words (), *expand_word (), *expand_word_no_split ();
 extern char *make_command_string ();
 
 extern Function *find_shell_builtin (), *builtin_address ();
@@ -912,7 +912,7 @@
       list = clauses->patterns;
       while (list)
 	{
-	  WORD_LIST *es = expand_word (list->word, 0);
+	  WORD_LIST *es = expand_word_no_split (list->word, 0);
 	  char *pattern = (es) ? es->word->word : "";
 
 	  if (fnmatch (pattern, word, FNM_NOESCAPE) != FNM_NOMATCH)
bash$ 

-- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 --
--
      |
   __-+-__      Jun Hamano
_-+ (|o|) +-_   junio@twinsun.com
  !   .   !

Newsgroups: gnu.bash.bug
From: p00185@psilink.com (Jeffrey W. Parker)
Subject: Problem running Bash 1.12 on IBM AIX370
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 08:13:31 GMT

Hello,
	I compiled BASH 1.12 on an IBM 370-type machine and it seemed
to compile just fine, but when I try to do virtually anything under the
shell I get the error "Illegal instruction" and it completely kills
my login.  Also, there is a core dump of zero length.  Has anyone else 
seen this?  I'd appreciate any help.  Here are the particulars:

			Bash Version: 1.12
			Machine & OS: IBM 4164 running AIX V1.2.1 on VM
			Compiler: MetaWare's High-C
			Description of Bug: Says "Illegal instruction",
					    and dies (kills login)
			Short Script to cause bug: $ echo $TERM


Thanks,
Jeff Parker
p00185@psilink.com



Newsgroups: gnu.bash.bug
From: junio@twinsun.COM (Jun Hamano)
Subject: 'case' broken?
Organization: Twin Sun, Inc. (El Segundo CA)
Distribution: gnu
Date: Sat, 26 Dec 1992 04:40:15 GMT

I found a small incompatibility between bash 1.12 and /bin/sh
SunOS 4.1.2.  I'm not sure if this is a bug, or `implementation
defined' incompatibility.

The following code shows that bash's `case' thinks a string
`abcd' matches *<newline>* while /bin/sh does not.

-- >8 -- 
shadow 100) bash -c 'echo $BASH_VERSION'
1.12.1
shadow 101) cat case.sh
NL='
'

for i in "$@"
do
	case $i in
	*$NL*) echo "case: $i: newline detected"
	esac
done
shadow 102) /bin/sh case.sh abcd 'ab
> cd'
case: ab
cd: newline detected
shadow 103) bash case.sh abcd 'ab
> cd'
case: abcd: newline detected
case: ab
cd: newline detected
shadow 104) 
-- >8 -- 
--
      |
   __-+-__      Jun Hamano
_-+ (|o|) +-_   junio@twinsun.com
  !   .   !

Newsgroups: gnu.bash.bug
From: quenton@cherniak.on.CA (Dennis Smith)
Subject: Bug (difference?) in case handling
Organization: Cherniak Giblon
Distribution: gnu
Date: Thu, 31 Dec 1992 04:11:25 GMT

I am running bash 1.12 and I have found a "difference" in case
handling.  Here is the example:

	case xxx in
	  *"?"*) echo ERROR;;
	esac

This example will echo "ERROR".  I suspect that the the resulting
string within bash after parsing is  *?*  and the quotes are
forgotten.  The quotes (according to /bin/sh) should escape the ? and
make it a simple character.  The 'case' above is looking for the
character "?" in the string "xxx".

If I double escape it:

	case xxx in
	  *"\?"*) echo ERROR;;
	esac

then it does NOT match, but then neither does:

	case "xxx?xxx" in
	  *"\?"*) echo ERROR;;
	esac

which still does NOT echo ERROR.

Given this last example, it appears impossible to look for "?" in a string.
Thus I consider this a bug.  I would prefer it worked like /bin/sh.
-- 
Dennis Smith, quenton@Cherniak.ON.CA, UUCP: ..!lsuc!cherniak!quenton
+1 416 771 7011, FAX +1 416 771 6288
Cherniak Giblon 10 Commerce Valley Dr. E. #400, Thornhill, Ont. CANADA L3T 7N7

Newsgroups: gnu.g++.bug
From: mwette@csi.jpl.nasa.gov (Matt Wette)
Subject: template bug in 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 18:54:18 GMT

There seems to be a bug in g++ when one hits multiple undefined templates ...

 Script started on Fri Jan  1 23:12:20 1993
 bash$ head -1 /etc/motd
 SunOS Release 4.1.3 (CSI.4) #1: Thu Dec 31 12:52:58 PST 1992
 bash$ cat zz.cc
 class A;
 class B;
 
 class T<A>;
 class T<B>;
 bash$ g++ -c zz.cc
 Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4/2.3.3/specs
 gcc version 2.3.3
  /usr/local/lib/gcc-lib/sun4-sunos4/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix zz.cc /usr/tmp/cca14349.i
 GNU CPP version 2.3.3 (sparc)
  /usr/local/lib/gcc-lib/sun4-sunos4/2.3.3/cc1plus /usr/tmp/cca14349.i -quiet -dumpbase zz.cc -version -o /usr/tmp/cca14349.s
 GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.2.
 zz.cc:4: parse error before `<'
 zz.cc:5: Non-template type 'T' used as a template
 zz.cc:5: Internal compiler error.
 zz.cc:5: Please report this to `bug-g++@prep.ai.mit.edu'.
 bash$ exit
 exit

 script done on Fri Jan  1 23:12:54 1993


Newsgroups: gnu.g++.bug
From: R.A.Rayner@massey.ac.NZ (R.A. Rayner)
Subject: fatal compiler error 11 buildin libg++
Summary: fatal signal 11 on SPARC making libg++
Keywords: fatal signal 11
Organization: Massey University, Palmerston North, New Zealand
Distribution: gnu
Date: Mon, 21 Dec 1992 22:22:16 GMT

	I posted a similar message to gnu.g++.help but I thought I'd better stick
one in here too.

On our SPARCstation 1+ with SunOS 4.1.1
when I'm trying to build libg++ with gcc I get

at the point where its doing 
  gcc -g -O -I.. -I. -I./../iostream -I./../g++-include -c Rational.cc

gcc: Internal compiler error: program cc1plus got fatal signal 11
*** Error code 1
make: Fatal error: Command failed for target 'Rational.o'



Richard Rayner
Massey University

-- 
------------------------------------------------------------------------------
TYPE	god = INTEGER ;
VAR	EricClapton : god ;
------------------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: richard@elroy.jpl.nasa.gov (Richard Weidner)
Subject: Probably a FAQ question, but where are the C++ system headers?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 17:59:20 GMT

I have installed gcc 2.3.3 and libg++-2.3. The gcc install moved
the c system header files in a fix-includes. But what about all
of the other system header files for C++? That is the functions
that return an int and are not in the c header files. 

Did I miss something somewhere in the install? Or is there something
else I should grab? 

Newsgroups: gnu.g++.bug