HDTenEightyP/NetNews huggingface dataset:
From: pjr@jet.UK (Paul J Rippin)
Subject: gdb-4.7 reference card
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 23 Dec 1992 16:36:14 GMT

Version: 4.7

We use gdb extensively on-site, and also make use of the reference card.
However, we do not have access to American paper size so I needed to print
the reference card on A4.  My knowledge of TeX is not very good so I've
worked out the changes by trial-and-error, but I do not know how to make
the card easily configurable.  If anyone can do this please do.


*** refcard.tex.orig	Sat Aug 15 12:05:57 1992
--- refcard.tex	Wed Dec 23 15:55:16 1992
***************
*** 63,71 ****
  % Three-column format for landscape printing on 8.5x11 paper
  
  % We want output .25 inch *from paper edge*; i.e. -.75in from TeX default
! \hoffset=-0.8in \voffset=-0.75in
  \newdimen\fullhsize
! \fullhsize=10.5in \hsize=3.3in
  \def\fulline{\hbox to \fullhsize}
  \let\lcr=L \newbox\leftcolumn\newbox\centercolumn
  \output={\if L\lcr
--- 63,72 ----
  % Three-column format for landscape printing on 8.5x11 paper
  
  % We want output .25 inch *from paper edge*; i.e. -.75in from TeX default
! % PJR
! \hoffset=-0.6in \voffset=-0.75in
  \newdimen\fullhsize
! \fullhsize=11.1in \hsize=3.5in
  \def\fulline{\hbox to \fullhsize}
  \let\lcr=L \newbox\leftcolumn\newbox\centercolumn
  \output={\if L\lcr
***************
*** 120,126 ****
  %-------------------- end font defs ---------------------------------
  
  %
! \vsize=8in
  \hyphenpenalty=5000\tolerance=2000\raggedright\raggedbottom
  \normalbaselineskip=9pt\baselineskip=9pt
  %
--- 121,128 ----
  %-------------------- end font defs ---------------------------------
  
  %
! % PJR
! \vsize=7.75in
  \hyphenpenalty=5000\tolerance=2000\raggedright\raggedbottom
  \normalbaselineskip=9pt\baselineskip=9pt
  %
***************
*** 136,147 ****
  \halign{%
  %COL 1 (of halign):
  \vtop{\hsize=1.1in\tt
! ##\par\vskip 2pt }\hfil
  %COL 2 (of halign):
  &\vtop{\hsize=2.1in\hangafter=1\hangindent=0.5em
! \rm ##\par\vskip 2pt}\cr
  %Tail of \long\def fills in halign body with \sec args:
! \noalign{{\bbf #1}\vskip 2pt}
  #2
  }
  }
--- 138,152 ----
  \halign{%
  %COL 1 (of halign):
  \vtop{\hsize=1.1in\tt
! % PJR
! ##\par\vskip 1pt }\hfil
  %COL 2 (of halign):
  &\vtop{\hsize=2.1in\hangafter=1\hangindent=0.5em
! % PJR
! \rm ##\par\vskip 1pt}\cr
  %Tail of \long\def fills in halign body with \sec args:
! % PJR
! \noalign{{\bbf #1}\vskip 1pt}
  #2
  }
  }


Hope this can be included in the next release.

Paul

+-------------------------------------------------------------------+
| Paul Rippin           | Voice  : 44-(0)235-465243                 |
| CODAS Division        | FAX    : 44-(0)235-464404                 |
| JET Joint Undertaking | E-mail : pjr@jet.uk                       |
| Abingdon              |-------------------------------------------|
| Oxfordshire           |                                           |
| OX14 3EA              |                                           |
| United Kingdom        |                                           |
+-------------------------------------------------------------------+


Newsgroups: gnu.gdb.bug
From: pierre@la.tce.COM (Pierre Willard)
Subject: ieee help
Reply-To: pierre@la.tce.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 02:44:24 GMT

Does anyone has the code to read ieee object files in gdb ?

Since ieee format is supported by the BFD library, I guess someone
must be using it... Unfortunately, there is no ieeeread.c in gdb.

regards
Pierre Willard (pierre@la.tce.com)



Newsgroups: gnu.gdb.bug
From: casper@fwi.uva.nl (Casper Dik)
Subject: GDB 4.7 installation fails on SVR4 with GNU egrep (+fix)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 14:49:30 GMT

GDB 4.7 installation fails when running ``munch'' on Solaris 2.1
when GNU egrep is installed and before /usr/bin/egrep in $PATH.
(Symptom: gdb/init.c won't compile)

GNU egrep parses the regexp '|__?initialize_' as
<empty> or __?initialize. System V egrep has the behaviour
expected by the writer of the gdb/munch script. (I.e.,
the regexp \|__?initialize_').

Fix  (works with both egreps, add \ before |):

*** gdb/munch-dist	Tue Dec 29 13:39:00 1992
--- gdb/munch	Tue Dec 29 13:39:43 1992
***************
*** 18,24 ****
  MUNCH_NM="${MUNCH_NM-nm} $NMOPT"
  if test "`$MUNCH_NM main.o | egrep main | egrep FUNC | egrep GLOB`" != "" ; then
      # System V Release 4 style nm
!     $MUNCH_NM $* | egrep '|__?initialize_' | egrep FUNC | \
        sed -e \
          's/^.*\(_initialize_[a-zA-Z0-9_]*\).*$/  {extern void \1 (); \1 ();}/'\
        | sort -u
--- 18,24 ----
  MUNCH_NM="${MUNCH_NM-nm} $NMOPT"
  if test "`$MUNCH_NM main.o | egrep main | egrep FUNC | egrep GLOB`" != "" ; then
      # System V Release 4 style nm
!     $MUNCH_NM $* | egrep '\|__?initialize_' | egrep FUNC | \
        sed -e \
          's/^.*\(_initialize_[a-zA-Z0-9_]*\).*$/  {extern void \1 (); \1 ();}/'\
        | sort -u



Casper

Newsgroups: gnu.gdb.bug
From: mccanne@horse.ee.lbl.gov (Steven McCanne)
Subject: old bug in valarith.c (gdb-4.7)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 23 Dec 1992 01:33:17 GMT

Someone posted this fix about four versions ago.  It must have gotten
lost since it still isn't in (as of 4.7).

Steve
-----
*** /tmp/,RCSt1a05227	Tue Dec 22 17:27:02 1992
--- valarith.c	Tue Dec 22 17:24:08 1992
***************
*** 400,406 ****
        if ((TYPE_UNSIGNED (VALUE_TYPE (arg1))
  	   || TYPE_UNSIGNED (VALUE_TYPE (arg2)))
  	  && (TYPE_LENGTH (VALUE_TYPE (arg1)) >= sizeof (unsigned LONGEST)
! 	      || TYPE_LENGTH (VALUE_TYPE (arg1)) >= sizeof (unsigned LONGEST)))
  	{
  	  unsigned LONGEST v1, v2, v;
  	  v1 = (unsigned LONGEST) value_as_long (arg1);
--- 400,406 ----
        if ((TYPE_UNSIGNED (VALUE_TYPE (arg1))
  	   || TYPE_UNSIGNED (VALUE_TYPE (arg2)))
  	  && (TYPE_LENGTH (VALUE_TYPE (arg1)) >= sizeof (unsigned LONGEST)
! 	      || TYPE_LENGTH (VALUE_TYPE (arg2)) >= sizeof (unsigned LONGEST)))
  	{
  	  unsigned LONGEST v1, v2, v;
  	  v1 = (unsigned LONGEST) value_as_long (arg1);

Newsgroups: gnu.gdb.bug
From: dodd@csl.sri.com (Chris Dodd)
Subject: gdb attach bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 02:09:52 GMT

I discovered that the `attach' command in gdb 4.7 doesn't work (at least on
sun4) -- it always gives an `attach not supported on this machine' error.
Simple patch to fix it:


*** inftarg.c.orig	Tue Dec 22 09:54:09 1992
--- inftarg.c	Tue Dec 22 09:58:19 1992
***************
*** 25,30 ****
--- 25,31 ----
  #include "wait.h"
  #include "gdbcore.h"
  #include "terminal.h"		/* For #ifdef TIOCGPGRP and new_tty */
+ #include "nm.h"			/* for ATTACH_DETACH */
  
  #include <signal.h>
  
-----------------------------

Chris Dodd
dodd@csl.sri.com

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: oleo 1.2 makefile invokes bison with wrong arguments
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 13:08:22 GMT

When parse.tab.c is out of date, the oleo 1.2 makefile invokes
`bison -y' without any other arguments, leading to an error.
Here is a patch.

Thu Dec 31 12:43:41 1992  Paul Eggert  (eggert@twinsun.com)

	* Makefile.in (parse.tab.c): Invoke bison with proper arguments.

===================================================================
RCS file: RCS/Makefile.in,v
retrieving revision 1.2
diff -c -r1.2 Makefile.in
*** Makefile.in	1992/12/29 02:05:50	1.2
--- Makefile.in	1992/12/31 12:43:41
***************
*** 111,117 ****
  	$(CC) $(ALL_CFLAGS) -o oleo $(all_objs) $(libs)
  
  parse.tab.c: parse.y
! 	$(BISON) $<
  	-mv y.tab.c $@
  busi.o : busi.c funcdef.h sysdef.h proto.h global.h utils.h cell.h \
  	eval.h errors.h  
--- 111,117 ----
  	$(CC) $(ALL_CFLAGS) -o oleo $(all_objs) $(libs)
  
  parse.tab.c: parse.y
! 	$(BISON) $(BISONFLAGS) parse.y
  	-mv y.tab.c $@
  busi.o : busi.c funcdef.h sysdef.h proto.h global.h utils.h cell.h \
  	eval.h errors.h  

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Meaning of `diff - -' ?
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 14:18:40 GMT

Hi, people.  This is a followup on my own report:

   This is GNU diff 2.0, installed with GNU C 1.41 under COFF
   encapsulation on a 386/ix 2.0.2 system, waiting for Hurd :-).

   The command `diff - -' exits right away with status 0 without reading
   standard input at all.  By contrast, `diff - /dev/null' reads standard
   input until end of file.

   It is not clear from the documentation what `diff - -' really means.
   I would suggest that this particular case be caught and diagnosed as
   improper usage, and be also documented as such.

Paul Eggert writes to me:

   Why must it be improper?

Standard input is some kind of `volatile' file.  Each time you look at
it, its content may differ.  The same way it would be improper for a C
compiler to optimize out:

	volatile int variable;
	[...]

	if (variable != variable)
	  {
	    /* some code */
	  }

it is improper for diff to optimize out `diff - -'.

But instead of torturing diff into reopening standard input for
getting the second instance of standard input, say, it's better to
leave the behaviour undefined, and implement it as an illegal usage.

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Date: Wed, 30 Dec 1992 14:50:59 -0500 (EST)
From: Tom Lord <lord+@andrew.cmu.edu>
To: info-gnu@gnu.ai.mit.edu
Cc: Tom Lord <lord+@andrew.cmu.edu>
Subject: Oleo 1.2
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
From: pinard@icule.UUCP (Francois Pinard)
Subject: Oleo 1.2 - second compilation attempt
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 03:37:36 GMT

Hi, people.  This is for Oleo 1.2, using GNU C 1.41 under COFF
encapsulation, on this 386/ix 2.0.2 system.  While configuring, I
forced `gcc -traditional'.  I applied the first two correction sets
recently suggested by Paul Eggert, before proceeding.

* `make distclean' removes $(all_objs) twice.  In fact, $(all_objs)
should not be part of the rule for distclean, since clean already
takes care of it.

* AC_ALLOCA should be used and alloca.c provided together with
parse.tab.c, which needs alloca.  Not every compiler has alloca.  (I
reported this already for Oleo 1.1).  More specifically, the
distribution should include alloca.c, and Makefile.in should have:

	extra_obs = @LIBOBJS@ @ALLOCA@

* Also, alloca is not properly defined in the provided parse.tab.c.
Just regenerating it with Bison 1.19 solves the problem, here.

* In io-curses.c, __SAVED_SYSV__ is uselessly undefined if SYSV is not
defined.  Just before SYSV is restored from __SAVED_SYSV__, it should
be undefined.

* In io-term.c, <sys/wait.h> is included, but does not exist on this
system.  Merely deleting the include solves the matter, here.

More later...

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: oleo 1.2 xrdb.c doesn't configure alloca properly
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 17:37:38 GMT

oleo 1.2 (gcc 2.3.3 -ansi -pedantic, SunOS 4.1.2) doesn't build properly
because xrdb.c uses alloca without defining it.  The problem is that xrdb.c
doesn't configure alloca properly.  Here's a patch.

*** xrdb.c	1992/12/31 15:54:06	1.2.1.1
--- xrdb.c	1992/12/31 16:04:32	1.2.1.2
***************
*** 19,24 ****
--- 19,43 ----
  /* Coopted for oleo -t 12/92 */
  /* Written by jla, 4/90 */
  
+ #ifndef alloca
+ #ifdef __GNUC__
+ #define alloca __builtin_alloca
+ #else /* __GNUC__ not defined.  */
+ #if HAVE_ALLOCA_H
+ #include <alloca.h>
+ #else /* not HAVE_ALLOCA_H */
+ #if defined (MSDOS) && !defined (__TURBOC__)
+ #include <malloc.h>
+ #else /* not MSDOS, or __TURBOC__ */
+ #if defined(_AIX)
+ #include <malloc.h>
+  #pragma alloca
+ #endif /* not _AIX */
+ #endif /* not MSDOS, or __TURBOC__ */
+ #endif /* not HAVE_ALLOCA_H */
+ #endif /* __GNUC__ not defined.  */
+ #endif /* alloca not defined.  */
+ 
  #ifdef emacs
  #include "config.h"
  #endif

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: dates on files in oleo 1.2 distribution
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 12:27:37 GMT

This is a minor point, but the files in the oleo distribution are all
dated 1992-12-27 or later, even though many of them haven't changed
since the previous distribution.  It would be helpful `ls -l F' would
output the most recent time that F was actually changed, instead of
outputting an artificial date that's more recent.

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: oleo 1.2 source should say where to send bug reports
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 12:19:53 GMT

Nowhere in the oleo 1.2 source code does it say that oleo bug reports
should be sent to bug-gnu-utils@prep.ai.mit.edu.

Newsgroups: gnu.utils.bug
From: karl@owl.HQ.ILeaf.COM
Subject: $(sharebindir)?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 19:56:44 GMT

Perhaps it would be useful if Makefiles distinguished binary executables
from sharable executables (i.e., shell scripts), by installing into
$(bindir) and, say, $(sharebindir), respectively.

$(sharebindir) could be $(prefix)/bin by default, so that if $(prefix)
and $(exec_prefix) are different, the sharable executables wind up in a
(presumably) sharable directory.

Whatever the default, if the Makefiles used something like this, it
would at least make it relatively painless to share what can be shared.

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: minor permissions problem in oleo 1.2 distribution
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 12:22:22 GMT

The files regions.h and random.c in the oleo 1.2 distribution are mode
640; they should have the same mode as all the other source files.
The following shell command fixes this.

	chmod a+r random.c regions.h

Newsgroups: gnu.utils.bug
From: eggert@bi.TWinsun.COM (Paul Eggert)
Subject: oleo 1.2 returns value in signal functions yielding void
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 13:23:37 GMT

When compiling oleo 1.2 (GCC 2.3.3, SunOS 4.1.2), I got the following
warning messages:

eval.c: In function `math_sig':
eval.c:1496: warning: `return' with a value, in function returning void
io-utils.c: In function `ignore_sig':
io-utils.c:85: warning: `return' with a value, in function returning void

Here is a patch.


Thu Dec 31 13:16:32 1992  Paul Eggert  (eggert@twinsun.com)

	* sysdef.h (SIGRET): Remove.  All invokers removed.
	This change might cause some harmless compiler warnings in
	old-fashioned hosts where signal functions yield `int', but
	that's better than always generating warnings in modern hosts
	where signal functions yield `void'.


===================================================================
RCS file: RCS/sysdef.h,v
retrieving revision 1.2
retrieving revision 1.2.1.1
diff -c -r1.2 -r1.2.1.1
*** sysdef.h	1992/11/28 03:29:02	1.2
--- sysdef.h	1992/12/31 13:16:32	1.2.1.1
***************
*** 33,41 ****
  
  #ifndef RETSIGTYPE
  #define RETSIGTYPE void
- #define SIGRET  return
- #else
- #define SIGRET  return 0
  #endif /* RETSIGTYPE */
  
  #ifndef VOIDSTAR
--- 33,38 ----
===================================================================
RCS file: RCS/eval.c,v
retrieving revision 1.2
retrieving revision 1.2.1.1
diff -c -r1.2 -r1.2.1.1
*** eval.c	1992/12/31 05:10:11	1.2
--- eval.c	1992/12/31 13:16:32	1.2.1.1
***************
*** 1493,1499 ****
  {
    stack[curstack].type = TYP_ERR;
    stack[curstack].Value = BAD_INPUT;
-   SIGRET;
  }
  
  #endif
--- 1493,1498 ----
===================================================================
RCS file: RCS/io-utils.c,v
retrieving revision 1.2
retrieving revision 1.2.1.1
diff -c -r1.2 -r1.2.1.1
*** io-utils.c	1992/12/31 05:09:50	1.2
--- io-utils.c	1992/12/31 13:16:32	1.2.1.1
***************
*** 82,88 ****
  ignore_sig (sig)
       int sig;
  {
-   SIGRET;
  }
  
  /* It's ok of this fails and generates signals.  In that case, 
--- 82,87 ----

Newsgroups: gnu.utils.bug
From: mike@sojurn.lns.pa.US (Mike Sangrey)
Subject: sed (my suggested fix is broke)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 04:59:14 GMT

This message refers to the patch that dealt with what I think is a bug with
   sed -n s/foo/bar/p

Specifically, in sed.c the change was

	  if (cur_cmd->x.cmd_regex.flags & S_WRITE_BIT
	      && !no_default_output)
	    ck_fwrite (line.text, 1, line.length,
		       cur_cmd->x.cmd_regex.wio_file);
	  if (cur_cmd->x.cmd_regex.flags & S_PRINT_BIT
-	      && !no_default_output)
	    ck_fwrite (line.text, 1, line.length, stdout);
	  break;

---- to ----

	  if (cur_cmd->x.cmd_regex.flags & S_WRITE_BIT
	      && !no_default_output)
	    ck_fwrite (line.text, 1, line.length,
		       cur_cmd->x.cmd_regex.wio_file);
	  if (cur_cmd->x.cmd_regex.flags & S_PRINT_BIT
+	      || !no_default_output)
	    ck_fwrite (line.text, 1, line.length, stdout);
	  break;


A few days ago I made this suggestion.  However, my simple fix causes
something else to break.  

For example:

----------------------
#!/bin/sh

az=abcdefghijklmnopqrstuvwxyz
AZ=ABCDEFGHIJKLMNOPQRSTUVWXYZ

/bin/sed -e "
	y/$AZ/$az/
	h
	y/$az/$AZ/
	G
        s/\(.\).*\n./\1/
"
----------------------

echo fooHaaHAA | this-script         # gives Foohaahaa with*out* my patch

And that is as it should be, at least with my understanding.  With my
patch, it gives two lines:

Foohaahaa
Foohaahaa

Hope this helps. 
Hope that any previous help that I helped with didn't unhelp.

Thanks again.

mike@sojurn.lns.pa.us
-- 
  |  UUCP-stuff:  ...!pitt!devon!sojurn!mike | "Disk space ...               |
  |  Internet  :  mike@sojurn.lns.pa.us      |      the final frontier."     |
  |  Fast-stuff:  (717) 396-9897             |                               |

Xref: sparky gnu.utils.bug:2271 gnu.announce:167
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: gnu.utils.bug,gnu.announce
Subject: gzip (GNU zip) beta release 0.5
Date: 23 Dec 92 18:03:21 GMT
Followup-To: gnu.utils.bug
To: info-gnu@prep.ai.mit.edu
Cc: Jean-loup Gailly <jloup@chorus.fr>

gzip version 0.5 is available for anonymous ftp from prep.ai.mit.edu
[18.71.0.38], in the file /pub/gnu/gzip-0.5.tar.Z

gzip (GNU zip) is a compression utility designed to be a replacement
for 'compress'. Its main advantages over compress are better
compression and freedom from patented algorithms.  The GNU Project
intends to make this the standard compression program for its system.

gzip currently uses by default the compression algorithm used in zip
1.9 (the portable pkzip compatible archiver). The gzip format was
however designed to accomodate several compression algorithms.
gunzip can currently decompress files in gzip 'deflate' format, zip
format or 'compress' format. The detection of the input format is
automatic.

Please send comments or bug reports to jloup@chorus.fr.

Jean-loup Gailly
jloup@chorus.fr

      [ Soon to be at these ftp sites as well.  Please try them
	before prep.ai.mit.edu!  thanx -gnu@prep.ai.mit.edu

	Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
	Australia: archie.oz.au:gnu
	Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
	  ftp.informatik.rwth-aachen.de:pub/gnu, nic.funet.fi:pub/gnu,
	  ugle.unit.no, isy.liu.se, ftp.stacken.kth.se, ftp.win.tue.nl,
	  ftp.diku.dk, ftp.eunet.ch, archive.eu.net
	United States: wuarchive.wustl.edu, ftp.cs.widener.edu,
	  uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
	  ftp.uu.net:systems/gnu

	For information on how to order GNU software on tape, check
	the file etc/DISTRIB in the GNU Emacs distribution, or e-mail
	a request to:	gnu@prep.ai.mit.edu
      ]
Newsgroups: gnu.utils.bug
From: dkarr@sierra.COM (David Karr)
Subject: Re: recursive dependencies
Organization: Sierra Geophysics,  Kirkland WA
Distribution: gnu
Date: Mon, 28 Dec 1992 18:02:15 GMT

I recently wrote a note about a problem with what I described as "recursive
dependencies" in Gnu make.  I realized I needed to give more specifics, as
my problem statement wasn't very clear.

(I would have responded to my original note, but someone sent me mail in
response to my original note before the moderated note I wrote got back to
my site...)

Essentially, I'm trying to write a more efficient "make depends" sequence.
The normal process of just running "cpp" (and variants) on the source file,
and looking for "^# 1 " lines works perfectly fine, but it is extremely
slow for our huge amount of source code.

The quick-and-dirty method I came up with would generate dependency lines
like this:

source.o : source.cc
source.cc : includefile1.h
source.cc : includefile2.h
includefile1.h : otherfile1.h
includefile1.h : otherfile2.h
includefile2.h : stillotherfile.h

instead of the more conventional:

source.o : source.cc includefile1.h otherfile1.h otherfile2.h \
    	   includefile2.h stillotherfile.h

As I mentioned in the original note, my new dependencies didn't seem to
work.  If I changed "stillotherfile.h", it wouldn't force source.o to be
regenerated.

I didn't see a mention of anything like this in the Gnu make manual, so I
am probably out of luck, but I'm still looking for possibilities.

--
David M. Karr
Sierra Geophysics, Inc.
ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
Phone: (206) 822-5200 (x343)


Newsgroups: gnu.utils.bug
From: laird@ptolemy.arc.nasa.gov (Phil Laird)
Subject: Re: gzip (GNU zip) beta release 0.5
Organization: NASA/ARC Information Sciences Division
Distribution: gnu
Date: Mon, 28 Dec 1992 19:57:36 GMT

-- 
   >>> PHILIP D. LAIRD  (Email: laird@pluto.arc.nasa.gov) <<<
   NASA Ames Research Center, AI Research Branch (FIA)
   MS 269-2!"Moffett Field, CA 94035.     (F|K\8l$G$I$&$>)
   Phone: (415)-604-3362.  FAX: (415)-604-3594.


Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: oleo 1.2 xrdb.c #endif XXX bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 17:36:57 GMT

oleo 1.2's xrdb.c contains `#endif HAVE_X11_X_H', which isn't allowed
in ANSI C.  Here's a patch.

===================================================================
RCS file: RCS/xrdb.c,v
retrieving revision 1.2
retrieving revision 1.2.1.1
diff -c -r1.2 -r1.2.1.1
*** xrdb.c	1992/12/29 00:23:27	1.2
--- xrdb.c	1992/12/31 15:54:06	1.2.1.1
***************
*** 510,513 ****
    XCloseDisplay (display);
  }
  #endif /* TESTRM */
! #endif HAVE_X11_X_H
--- 510,513 ----
    XCloseDisplay (display);
  }
  #endif /* TESTRM */
! #endif /* HAVE_X11_X_H */

Newsgroups: gnu.utils.bug
From: cb@xis.xerox.com (Christopher Bader)
Subject: recode-3.2.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 22:29:59 GMT

You appear to be using the original IBM PC character set
in recode-3.2.4.  You  should instead be using the superset
called the "code page 850" character set.  You'll find the
chart for this character set in the back of IBM's manual
for DOS 3.3 or higher.

Code page 850 includes support for Danish, Norwegian, and
Portuguese, which is lacking in the original PC character set.

Your use of the old PC character set shows up in coverting
Latin1 Portuguese text to Macintosh.  Both of these support
Portuguese, but because you go via IBM PC, the text is clobbered!

Let me know if any of this requires further explanation.

			-- Christopher Bader



Newsgroups: gnu.utils.bug