HDTenEightyP/NetNews huggingface dataset:
From: willoch@geos01.sinet.slb.com (thorbjorn willoch)
Newsgroups: gnu.gdb.bug
Subject: Strange behaviour regarding  environment variables.
Date: 4 Sep 92 02:27:39 GMT
Distribution: gnu
Organization: GECO-PRACLA Europa and Arica Marine Region

geos112:recording.stage>cat t.c
main(int argc,char **argv)
{
 printf("%s\n",getenv(argv[1]));
}


geos112:recording.stage>a.out TRILOGY
/homedirs/triacq/BASELINE


geos112:recording.stage>gdb a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) r TRILOGY
Starting program: /tmp_mnt/homedirs/triacq/recording.stage/a.out TRILOGY
/homedirs/triacq/bsl

Program exited with code 02.
(gdb) show env TRILOGY
TRILOGY = /homedirs/triacq/BASELINE
(gdb) geos112:recording.stage>

When running the program above gdb, a previous value of TRILOGY is used. 
Gdb itself sees the right environment, but the program it runs sees something 
different.

I can do the example again and again while in the shell., but I am not able to redo it 
if I start a new session.


Thorbjorn
From: pfieland@citron.sw.stratus.com (Peggy Fieland)
Newsgroups: gnu.gdb.bug
Subject: yacc problem with c-exp.y
Date: 25 Aug 92 19:38:28 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I used gdb-4.6 on a Stratus i860 (svr4).
The version of yacc is:

yacc:Standard C Development Environment , (SCDE) 5.0 12/08/89

As the comment in c-exp.y states, the redefine of malloc and realloc
have to appear in the generated c-exp.tab.c AFTER the include of
malloc.h generated by the svr4 YACC.  Unfortunately, at least
with the version of yacc on our system, the version of c-exp.y distributed
with gdb-4.6 generates them in the wrong order as the following
error message from the make demonstrates:

       cc -c -g      -I. -I. -I./../include -I./../readline  c-exp.tab.c
"/usr/include/malloc.h", line 46: identifier redeclared: xmalloc
"/usr/include/malloc.h", line 48: identifier redeclared: xrealloc

The fix is to include the redefinition at the TOP of the rules
section rather than at the BOTTOM of the declaration section, as
it seems that yacc is generating the includes when the declaration
section is finished.  Here is a fix:

diff -c /home/tools/gnu/gdb-4.6/gdb/c-exp.y gdb-4.6/gdb-4.6/gdb/c-exp.y
*** /home/tools/gnu/gdb-4.6/gdb/c-exp.y Tue Jul 14 03:34:19 1992
--- gdb-4.6/gdb-4.6/gdb/c-exp.y Tue Aug 25 15:24:03 1992
***************
*** 193,198 ****
--- 193,202 ----
  %type <bval> block
  %left COLONCOLON

+
+

+ %%
+
  %{
  /* Ensure that if the generated parser contains any calls to malloc/realloc,
     that they get mapped to xmalloc/xrealloc.  We have to do this here
***************
*** 204,212 ****
  #define malloc        xmalloc
  #define realloc       xrealloc
  %}
-
-

- %%

  start   :     exp1
        |       type_exp
--- 208,213 ----
Newsgroups: gnu.gdb.bug
From: jimb@occs.cs.oberlin.edu (Jim Blandy)
Subject: Emacs runs slower under GDB 4.6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 22:57:51 GMT

I am debugging FSF Emacs 18.58 under GDB 4.6 on a DECstation running
Ultrix 4.2a.

Emacs 18.58 runs *much* slower under GDB 4.6 than under GDB 4.5.  I
can outtype Emacs running under GDB 4.6, but it runs at a normal speed
under GDB 4.5.

To reproduce (please do!), compile Emacs 18.58 with X11 support on a
DECstation, run it under GDB 4.6 so that it opens its own X window
(i.e. it's using the X interface, not the termcap interface), and try
to type fast.  For comparison, find an old copy of GDB 4.5 lying
around somewhere, and try the same thing.

I'm actually asking for the sake of Emacs 19, which exhibits the same
behavior.  I'd use GDB 4.5, but it crashes when I try to set
breakpoints in certain functions.  So I'm kind of stuck with VERY SLOW
debugging until this is fixed.

It would make my day if whoever is responsible for GDB bug reports
would send me an ack message.  It would make my week if someone sent
me a patch.

Thanks for your time!

Newsgroups: gnu.gdb.bug
From: azhao@cs.arizona.edu (Qiang Alex Zhao)
Subject: Where to get gdb's documentation?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 03:20:50 GMT

Hi,

Is there a place where I can ftp a documentation of gdb in PostScript
format, or in TeX/troff/...? Thanks in advance.

Sincerely,
= Q. Alex Zhao


Newsgroups: gnu.gdb.bug
From: jimb@occs.cs.oberlin.edu (Jim Blandy)
Subject: very nonfatal error in GDB manual
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 17:04:52 GMT

The following sentence appears in the node "Messages/Warnings" in the
info files distributed with GDB 4.2 and 4.5:

       By default, GDB is cautious, and asks what sometimes seem to be a
    lot of stupid questions to confirm certain commands.

The noun clause 'a lot of stupid questions', while referring to many
stupid questions, is singular - 'a lot' is just one lot.  Therefore,
one should use 'seems', not 'seem':

       By default, GDB is cautious, and asks what sometimes seems to be a
    lot of stupid questions to confirm certain commands.

This error renders the GDB manual practically unusable.  :-)

Newsgroups: gnu.gdb.bug
From: pierre@la.tce.COM (Pierre Willard)
Subject: cast integers into pointers
Reply-To: pierre@la.tce.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 02:18:52 GMT

I found a problem in gdb-4.5 on systems where integers and
pointers are NOT the same size.

(gdb) p (void*) 5
Invalid cast.
(gdb) p (void*) 500000
$1 = (void *) 0x7a120
(gdb) p (void*) (long) 5
$2 = (void *) 0x5
(gdb) 

A possible fix is the following : at the end of value_cast function
(in valops.c) do :

    {
	/* Always accept a cast of an integer into a pointer,
    even when the sizes are not equals !
	 */
      if (code1 == TYPE_CODE_PTR && scalar)
		return value_from_longest (type, value_as_pointer (arg2));	

      error ("Invalid cast.");
      return 0;
    }

Important: I also noticed that in value_cast(), in case pointers
and integers are the SAME size, value_as_pointer() is NOT called
to transform the value into a pointer, which is NOT very clean...

Let me know your comments.
Regards
Pierre Willard

Newsgroups: gnu.gdb.bug
From: casadei@verona.mit.edu (Stefano Casadei)
Subject: invoking class member functions
Organization: Massachusetts Institute of Technology
Distribution: gnu
Date: Tue, 25 Aug 1992 23:02:23 GMT

I noticed that there have been complaints recently about gdb not beeing
able to invoke class member functions. I have been using gdb-4.6 for a while
on an Sun SPARC IPC with OS 4.1.1 with gcc-2.2.2. I found gdb very useful but I should
say that I have been consistently unable to invoke class member functions,
getting answers from gdb similar to those reported in previous messages.

Then on page 87 of the manual gdb-4.6/gdb/doc/gdb.texi I found the following
warning which says, more or less, that one should not expect to be be able
to do so, unless the machine does not have the right object file format.
Not being able to discern wether or not my machine has the right format,
and not being able to invoke class member functions, I assumed my machine
HAS NOT the right format. (By the way, after reading the warning, can anyone
tell me how I can find out which object code format is used by my machine ?).

Here is the warning from the manual:

----------------------cut here ---------------------------------------

.............[deletion].......(this section is talking about C++ features)........
@quotation
@emph{Warning:} Most of these extensions depend on the use of additional
debugging information in the symbol table, and thus require a rich,
extendable object code format.  In particular, if your system uses
a.out, MIPS @sc{ecoff}, RS/6000 @sc{xcoff}, or Sun @sc{elf} with stabs
extensions to the symbol table, these facilities are all available.
Where the object code format is standard @sc{coff}, on the other hand,
most of the C++ support in GDB will @emph{not} work, nor can it.
For the standard SVr4 debugging format, @sc{dwarf} in @sc{elf}, the
standard is still evolving, so the C++ support in GDB is still
fragile; when this debugging format stabilizes, however, C++ support
will also be available on systems that use it.
@end quotation

@enumerate

@cindex member functions
@item
Member function calls are allowed; you can use expressions like
............[deletion]..........

------------------------- cut here ------------------------------------


So, (someone should correct me if I am wrong) if you are unable to invoke 
memeber functions, that's because your "object code format" does not allow to do so.

Enjoy gnuorself.


Newsgroups: gnu.gdb.bug
From: helgaas@convex.com (Bjorn Helgaas)
Subject: User-defined commands - adding arguments, control structures
Summary: Is anyone working on this?
Keywords: user-defined commands, arguments, control structures
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Distribution: gnu
Date: Tue, 25 Aug 1992 16:54:21 GMT

It would be very useful if user-defined commands could take arguments
and include loops and conditionals.  I may end up adding some of this
functionality myself, but it looks like quite a lot of work, so I'm
wondering whether anyone else is already working on it.

Bjorn (helgaas@convex.com)

Newsgroups: gnu.gdb.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: Bug/feature request in gdb-4.6.
Organization: U. C. Berkeley
Distribution: gnu
Date: Thu, 27 Aug 1992 19:32:51 GMT

In article <9208261514.AA24807@turing.think.com!> randys@think.com (Randall Smith) writes:
!>    In the function define_symbol in gdb-4.6 read the following words:

[ code containing "abort() if unexpected characters appear in the symbol name]

!>    I question the wisdom of calling abort from within define_symbol.
!>  Specifically, you may be (I am) debugging a mixed C/some other random
!>  language program and wish to use gdb on it.  That other random language
!>  may have added extensions to the dbx symbol format that gdb doesn't
!>  understand, but that do not render gdb useless in debugging that
!>  language.

Could this and similar practices have something to do with why gdb aborts
when debugging acc (Sun's bundled compiler) code, because it does not
recognize Sun's (undocumented) extensions?  There should be some less
drastic response to "I don't understand this symbol information" than
"kablooie".

(I recognize that this can be difficult to do, since there is sometimes
a re-synchronization step required).




--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.gdb.bug
From: lev@gamut.lkg.dec.com (Lev Vaitzblit)
Subject: binutils-beta-1.94 bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 06:18:53 GMT

	Hi,

I'd like to bring to your attention a couple of problems with 
binutils-beta-1.94 running in a cross-compile environmemt. 

Here is my configuration:
host: DECstation 5000/Ultrix
target: i386/a.out

My current software:
gcc 2.2.2
binutils-beta-1.94

PROBLEM 1:

The linker does not complain about unresolved references.

SOLUTION:

I was able to track this one down. The problem is the incorrectly
defined endianness of the 386 machine. It's in the definition of the
bfd_target in the aout-target.h file.

PROBLEM 2:

Incremental linking (ld with -i or -r) doesn't seem to work. An object file
produced by linking with -i or -r switch does not retain any relocation
entries.


If the incremental linking problem has an easy fix, I would greatly appreciate
if you could advise me about how to solve it.

Also, when do you expect to have the next release of binutils?

	Thanks in advance for any help,

	Regards,
	Lev.

P.S. I mailed the same message to bothner@cygnus.com



Newsgroups: gnu.utils.bug
From: casadei@verona.mit.edu (Stefano Casadei)
Subject: _memmove
Organization: Massachusetts Institute of Technology
Distribution: gnu
Date: Fri, 4 Sep 1992 00:28:51 GMT

While compiling for sed (1.09) on an IPC SparcSun with OS 4.1.1 I got the following message:

make
gcc  -O -c -g  -DSTDC_HEADERS=1 -I/usr/users/casadei/gnu/sed-1.09 sed.c
sed.c: In function `execute_program':
sed.c:1132: warning: assignment makes pointer from integer without a cast
sed.c:1248: warning: assignment makes pointer from integer without a cast
gcc  -O -c -g  -DSTDC_HEADERS=1 -I/usr/users/casadei/gnu/sed-1.09 utils.c
gcc  -O -c -g  -DSTDC_HEADERS=1 -I/usr/users/casadei/gnu/sed-1.09 regex.c
gcc  -O -c -g  -DSTDC_HEADERS=1 -I/usr/users/casadei/gnu/sed-1.09 getopt.c
gcc  -O -c -g  -DSTDC_HEADERS=1 -I/usr/users/casadei/gnu/sed-1.09 getopt1.c
gcc  -O -o sed -g sed.o utils.o regex.o getopt.o getopt1.o 
ld: Undefined symbol 
   _memmove 
collect: /usr/bin/ld returned 2 exit status
*** Error code 1
make: Fatal error: Command failed for target `sed'




Where is the function _memmove supposed to be ?

Thank you. (Please, reply also to casadei@cesena.mit.edu)


Newsgroups: gnu.utils.bug
From: carlton@scws8.harvard.edu (david carlton)
Subject: Re: more thoughts on fileutils
Organization: Citizens for Boysenberry Jam
Distribution: gnu
Date: Mon, 31 Aug 1992 18:59:07 GMT

In article <9208282057.AA12744@wookumz.gnu.ai.mit.edu>, mib@gnu.ai.mit.edu (Michael I Bushnell) writes:

> In GNU, nodes can be both directories and ordinary files.
...
> Suppose "foo" is such a node.  In that case "mv bar foo" should
> delete the existing foo (and the virtual hierarchy underneath it),
> replacing it with bar.  "mv bar foo/" should move bar into the
> directory foo, giving it the name foo/bar, and leaving the rest of
> the virtual hierarchy under foo untouched.

This sounds really bad to me.  If foo is going to act like a
directory, it should act like a directory, and one of the qualities of
acting like a directory is that "mv bar foo" renames "bar" to
"foo/bar".  If you do things any other way, then all sorts of typing
idioms that people have are no longer going to work, shell scripts and
programs are going to break, and so forth.

david carlton
carlton@husc.harvard.edu

       Go on, EMOTE!  I was RAISED on thought balloons!!

Newsgroups: gnu.utils.bug
From: hxl@chopin.UUCP (Charlie Xiaoli Huang)
Subject: indent 1.6 and typedef
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 17:07:34 GMT

Hi,

I installed indent 1.6 on a Sun IPC runnning 4.1.1 and 
using gcc 2.2.2. Everything seemed fine except for the
following annoying "feature": it forces a newline after
each of of typedef.

For example:

	original:

	typedef struct foo {
		int bar;
	} foo_t;

The outcome will always become

	typedef struct foo {
		int bar;
	}
	foo_t;

(the placement of braces and indentations are subject to
options and indent.pro, but the newline is always forced
before "foo_t").

Anyway I can turn this off? RTFM didn't help much on this
"feature".

Thanks,

hxl

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: bison always generates .h file
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 10:44:45 GMT

Bison 1.18 generates an (empty) .h file even when it detects an error
that prevents generation of the .c file with the parser itself.  I think
it would be cleaner to avoid this.

Newsgroups: gnu.utils.bug
From: bhagwan@taos.agps.lanl.gov
Subject: indent 1.6 bug (?)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 09:24:18 GMT

	Consider the following C code:

/*
 *  Test
 */

main ()
{
	int code;

	/*
	 *  Thang.
	 */
	code = 1;
}


	indent -cbd test.c  produces:

/*
 *  Test
 */

main ()
{
  int code;

  /*
	 *  Thang.
	 */
  code = 1;
}

	which is not quite what I thought it would:

/*
 *  Test
 */

main ()
{
  int code;

  /*
   *  Thang.
   */
  code = 1;
}

	Maybe I just can't figure out the sequence of options that
	produce this result.  I don't want to format (paragraph) these
	comments---just have them move to the same column as the code
	with internal alignment unchanged.

	Possibly a problem because of tabs in the original file?


Thanks,
Allen L. McPherson               Member Holstein Aerobatic Club
Los Alamos National Laboratory   Advanced Graphics and Parallel Systems
Box 1663  Group:A-10  MS:J488    {bhagwan|alm|allen|mcpherson}@agps.lanl.gov
Los Alamos, NM   87545           Voice: (505) 667-8495  Fax: (505) 665-2083

Newsgroups: gnu.utils.bug
From: pollock@eggo.csee.usf.edu (Wayne Pollock)
Subject: Version 1.7 of the GNU shell programming utilities
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 00:13:55 GMT

While not (currently) a user of Gnu, I have to wonder why the programming
utilities echo and xargs aren't in the same package as tee and test?

Just curious,

Wayne Pollock (The MAD Scientist)
Internet:	pollock@eggo.csee.usf.edu

Newsgroups: gnu.utils.bug
From: jh@efd.lth.se (Joergen Haegg)
Subject: bug in tar?
Reply-To: jh@efd.lth.se (Joergen Haegg)
Organization: Lund Institute of Technology
Distribution: gnu
Date: Tue, 1 Sep 1992 07:55:35 GMT

I found an interesting anomaly when using the '-C' option (change directory).
Gtar (1.10) ignores '-C' when I use it together with '-T' (list of files).
But only when I use gtar locally, -f /dev/xxx. 

It works fine when I use -f user@host:/dev/xxx.

Bug or feature?

By the way, are there any plans on changing the mangling of long filenames?
It's very difficult to get back one mangled file from the backup.
Especially if the tape has several hundred megabytes mangled files... :-|.
I have to save the error-log and search for the new mangled filename.

Would it not be easier saving the long name as a special file just before
the real file?


Newsgroups: gnu.utils.bug
From: larry@mitra.mitra.COM (Larry Williamson)
Subject: Mangled Names and gnu tar
Organization: Mitra Imaging Inc.
Distribution: gnu
Date: Fri, 28 Aug 1992 05:43:37 GMT

I've seen a posting some time back that purported to fix a bug in gnu
tar that causes it to consider very long file names as mangled.

The filenames in our case are created by interleaf in the users
desktop.  The filenames are very long indeed.

Would someone repost this message, or email it to me?

Thanks

-Larry

Newsgroups: gnu.utils.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: diff Makefile bug (probably the 1e6th report)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 07:08:23 GMT

The handling of ALLOCA in the Makefile shows signs that it was
never actually used.  The diff to make it work follows.

Chris Metcalf
MIT Lab for Computer Science

*** Makefile.DIST	Mon Aug 31 10:44:04 1992
--- Makefile	Mon Aug 31 11:11:24 1992
***************
*** 45,51 ****
  # Some System V machines do not come with libPW.  If this is true, use
  # the GNU alloca by switching the comment on the following lines.
  ALLOCA = 
! # ALLOCA = $(archpfx)/alloca.o
  
  bindir=/usr/local/bin
  prefix=
--- 45,51 ----
  # Some System V machines do not come with libPW.  If this is true, use
  # the GNU alloca by switching the comment on the following lines.
  ALLOCA = 
! # ALLOCA = $(archpfx)alloca.o
  
  bindir=/usr/local/bin
  prefix=
***************
*** 58,64 ****
  objs=$(archpfx)diff.o $(archpfx)analyze.o $(archpfx)io.o $(archpfx)context.o \
       $(archpfx)ed.o $(archpfx)normal.o $(archpfx)util.o $(archpfx)dir.o \
       $(archpfx)regex.o $(archpfx)ifdef.o $(archpfx)version.o \
!      $(archpfx)getopt.o $(archpfx)getopt1.o
  tapefiles = $(srcs) README diagmeet.note Makefile COPYING ChangeLog
  
  all: $(archpfx)diff $(archpfx)diff3
--- 58,64 ----
  objs=$(archpfx)diff.o $(archpfx)analyze.o $(archpfx)io.o $(archpfx)context.o \
       $(archpfx)ed.o $(archpfx)normal.o $(archpfx)util.o $(archpfx)dir.o \
       $(archpfx)regex.o $(archpfx)ifdef.o $(archpfx)version.o \
!      $(archpfx)getopt.o $(archpfx)getopt1.o $(ALLOCA)
  tapefiles = $(srcs) README diagmeet.note Makefile COPYING ChangeLog
  
  all: $(archpfx)diff $(archpfx)diff3

Newsgroups: gnu.utils.bug
From: hurst@garlock.jpl.nasa.gov (Ken Hurst)
Subject: GNUmake bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 22:52:52 GMT

First: I am running:
garlock{hurst}50: make -v -f /dev/null
GNU Make version 3.60, by Richard Stallman and Roland McGrath.
Copyright (C) 1988-1991 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

make: No targets.  Stop.


The bug?
When a rule is to execute a csh script on a Sun SPARC, I get:

garlock{hurst}63: make test_csh
script.csh 
csh: Permission denied
make: *** [test_csh] Error 1

This works fine on an hp730 running GNUmake made from the
same source. It also works fine when using the native Sun
make. Here is a demo. garlock is a sun4, cobra is an hp730

garlock{hurst}65: make test_csh
script.csh 
csh: Permission denied
make: *** [test_csh] Error 1

garlock{hurst}66: make test_sh
script.sh
sh script here!

garlock{hurst}67: /bin/make test_csh
script.csh 
this is a csh script
garlock{hurst}68:


cobra{hurst}53: make test_csh
script.csh
this is a csh script

cobra{hurst}54: make -v -f /dev/null
GNU Make version 3.60, by Richard Stallman and Roland McGrath.
Copyright (C) 1988-1991 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

make: No targets.  Stop.
cobra{hurst}55:


Here is the Makefile:

-----

test_csh:
	script.csh 

test_sh:
	script.sh

-----

here is sript.csh

------

#! /bin/csh -f
echo this is a csh script

------

here is script.sh
 
-----

echo sh script here!

-----

 |/   | Ken Hurst  				  			
 | \  | hurst@garlock.jpl.nasa.gov		MS 238-600		
 |----| voice: (818) 354-6637 office		Jet Propulsion Laboratory 
 |  | |        (805) 270-9707 home		4800 Oak Grove Dr.	  
 |\_/ | FAX:   (818) 393-4965 			Pasadena, California  91109

Newsgroups: gnu.utils.bug
From: root@schulz.unisa.EDU.AU (System PRIVILEGED Account)
Subject: "make" in grep-1.6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 19:50:31 GMT

G'day,

With limited knowledge of UNIX, I am trying to 'make' the grep-1.6 package.
I've typed ./configure to produce a Makefile for our system, which looks OK,
but 'make' produces this sort of error:

cc -g -I. -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1  -c dfa.c
ccom: Warning: dfa.c, line 162: "const" not yet implemented
           const _charset src;
      ----------------------^
ccom: Error: dfa.c, line 162: illegal type combination
           const _charset src;
      ----------------------^
ccom: Error: dfa.c, line 168: illegal indirection
          dst[i] = src[i];
      ------------------^
ccom: Warning: dfa.c, line 193: "const" not yet implemented
           const _charset s1;
      ---------------------^
ccom: Error: dfa.c, line 193: illegal type combination
           const _charset s1;

and so on ... always complaining about "const"

This is on a DECstation 4000, running Ultrix V4.2A, and no gcc.
Can you help? 

Margaret

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: tar 1.10 documentation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 09:40:33 GMT

   Resent-Date: Tue, 1 Sep 92 12:55:46 EDT
   Resent-Message-Id: <9209020316.AA15162@cookie-crisp>
   Date: Tue, 1 Sep 92 12:55:46 EDT
   From: Mark Flynn <flynn@nematic.kent.edu>
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   I have just installed gnutar and it works great. This is what they have at
   wuarchive.wustl.edu, so I guess it's pretty up to date. Anyways, I have
   two questions (not bugs: sorry)

   1) Is the new doc close to being done?

Yes.  It will probably (but not certainly) be in the upcoming release
of 1.11.

   2) I know that I'm not supposed to send bug reports about the old documentation,
   but I would really like to have something. And the first line in tar.texinfo
   is:

   \input texinfo ....

   This presumably defines various macros, but wasn't included with the
   distribution. Is this avialable?

The macros are texinfo.tex, and were inadvertently left out of the
1.10 distribution.  You should not trust that manual too much...

	-mib