HDTenEightyP/NetNews huggingface dataset:
From: rwp@hprwp.fc.hp.com (Bob Proulx)
Subject: Latest GNU versions? [was: GNU tar-1.11 problems]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 11:31:18 GMT

Michael writes:
>    GNU maintainers generally don't have time to figure out which bugs
>    have been fixed by the latest release and which have not--so save
>    us the trouble, and don't send in bug reports for old versions of
>    programs.

Francois Pinard writes:
> It is *preferable* to send bug reports for latest versions, I agree.
> However, we should not make this a must.  All bug reports should be
> welcome, whatever the version they apply to.

Thank you!  I had felt that I had been unjustly rebuked!  I had
prepared a very flameful response, but then let it sit unmailed while
I cooled down.  If nothing else this short note from Francois has done
some good PR for the FSF with me.

> No user should fear reporting problems with GNU products, or feel

Which is exactly what I felt after getting that response.  I had
pulled tar-1.11 just a few days before.  It *was* the newest and most
current version at that time.  And it looks like 1.11.1 was released
almost immediately after that!

On prep.ai.mit.edu:~/pub/gnu/
-rw-r--r--  1 14910    wheel      280367 Sep 15 19:46 tar-1.11.1.tar.Z

So I thought I *did* have the latest version but figured that since
the problems were pretty obvious that there must be something better
cooking somewhere.  (Notice from my bug report that I did ask if there
was a newer version.  I was thinking of the maintainers current copy,
however. :-)  I also offered to supply patches to fix the problems
that I had found.  I want brownie points for that.  :-)

I was previously unaware of the news group gnu.utils.bug or I would
have known about the release of the newer version while I was
debugging the old one.  I will keep an eye on it from now on.

Simple pointers like the one I got to look in that news group go a
long way!  I might suggest putting that in the README file which is
where I got the bug-gnu-utils@prep.ai.mit.edu address.  I am not sure
where it goes, probably to thousands, so please pardon the intrusion
everyone.

Meanwhile, keep up the good work!

Bob Proulx
"Testing out 1.11.1"
rwp@fc.hp.com

Newsgroups: gnu.utils.bug
From: phillips@swanee.ee.uwa.oz.au (Christopher Phillips)
Subject: gs386 selectdevice problems
Organization: Elec Eng, Univ of Western Australia
Distribution: gnu
Date: Sat, 3 Oct 1992 13:48:27 GMT

We have been merrily using gs386 on a horrible amstrad ibm-compat, printing
stuff on a HPlaserjet3p with no problems. When said amstrad died, we obtained
a not-quite-as-unreliable HP.  Transfer all files across, and all works hoopily,
except that now
gs386 -sDEVICE=ljet3 frogs.ps
bombs out with an 'unknown error in setdevice'. The same error occurs if
(ljet3) selectdevice
is used within gs386.  Sending text to prn works fine.  Help!

Ta muchly,
Christopher Jam & Jeanette Tart.

--
Christopher Jam	__________________________________________________
phillips@swanee.ee.uwa.edu.au			c64 forever!!!!
300,000 c64's were sold in the fiscal year ending June 1991 :)
------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: beatty@cs.cmu.edu (Derek Beatty)
Subject: tar 1.11.1 --listed-incremental with --atime-preserve
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 10:35:22 GMT

Do these two options really work together?  Are you really getting incremental
backups when you use the scripts you provide?  I had to take out --atime-
preserve to make the scripts work incrementally on a NeXT.  Otherwise, level-1
seemed to dump everything accessed since the level-0, which of course includes
everything on the level-0 dump.

By the way, here's yet another hint for people using the NeXT workstation's
builtin floppy drive: use --info-script='/usr/etc/disk -e /dev/rfd0a', and
also insert the same command in the scripts at the bottom of the backup-dirs
loop and also inside the backup-files conditional.

 -- Derek


Newsgroups: gnu.utils.bug
From: monty@proponent.COM (Monty Solomon)
Subject: diff 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 01:35:52 GMT

I get the following warnings trying to compile diff 2.0 on the NeXT (NeXTstep  
2.1).

I can send the man page for wait if necessary.

gcc -O -c -g  -DSYSDIR=1 -DSTDC_HEADERS=1 -Dpid_t=int -DHAVE_DUP2=1  
-DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_ST_BLKSIZE=1 diff.c
system.h:92: warning: index redefined
system.h:93: warning: rindex redefined
system.h:94: warning: bcopy redefined
system.h:95: warning: bcmp redefined
system.h:96: warning: bzero redefined

gcc -O -c -g  -DSYSDIR=1 -DSTDC_HEADERS=1 -Dpid_t=int -DHAVE_DUP2=1  
-DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_ST_BLKSIZE=1 regex.c
regex.c:50: warning: bcmp redefined
regex.c:51: warning: bcopy redefined
regex.c:52: warning: bzero redefined

gcc -O -c -g  -DSYSDIR=1 -DSTDC_HEADERS=1 -Dpid_t=int -DHAVE_DUP2=1  
-DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_ST_BLKSIZE=1  
-DDIFF_PROGRAM=\"/usr/local/bin/diff\" ./diff3.c
./diff3.c: In function read_diff:
./diff3.c:1219: warning: argument passing between incompatible pointer types

gcc -O -c -g  -DSYSDIR=1 -DSTDC_HEADERS=1 -Dpid_t=int -DHAVE_DUP2=1  
-DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_ST_BLKSIZE=1  
-DDIFF_PROGRAM=\"/usr/local/bin/diff\" ./sdiff.c
./sdiff.c: In function waitpid:
./sdiff.c:236: warning: argument passing between incompatible pointer types

Newsgroups: gnu.utils.bug
From: uddeborg@sisu.SE (Goeran Uddeborg)
Subject: Re: make-3.62, Error with `+=' variable concatenation
Organization: Swedish Institute of Systems Development
Distribution: gnu
Date: Fri, 25 Sep 1992 07:31:10 GMT

In article <199209241452.AA07992@mail.Germany.EU.net> muewi@oz.INformatik.uni-bremen.DE (Wilhelm Mueller) writes:
>The following Makefile
>
>-- 8< ------------------------------------------------------------ >8 --
>dummy = abc
>
>dummy += def
>
>all:
>	@echo $(dummy)
>-- 8< ------------------------------------------------------------ >8 --
>
>will echo just `abc', while Sun's make produces `abc def'.

Quoting from the node "Variables" in the documentation of GNU make:

    A variable name may be any sequence characters not containing `:',
    `#', `=', or leading or trailing whitespace.

So your makefile assigns the value "abc" to the variable "dummy", and
the value "def" to the variable "dummy +".

You can achieve what you intend by

    dummy = abc

    dummy := $(dummy) def

    all:
	    @echo $(dummy)

Newsgroups: gnu.utils.bug
From: ericb@lsid.hp.com (Eric Backus)
Subject: sed-1.09 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Sep 1992 21:56:58 GMT

I think I've found a bug in GNU sed-1.09.  Here is how to reproduce
the bug:


$ echo 1 > tester
$ echo 2 >> tester
$ echo 3 >> tester
$ gsed --version
GNU sed version 1.09
Usage: gsed [-nV] [--quiet] [--silent] [--version] [-e script]
        [-f script-file] [--expression=script] [--file=script-file] [file...]
$ gsed -e "1,1s/^/BEGIN /" tester
BEGIN 1
BEGIN 2
3
$ /bin/sed -e "1,1s/^/BEGIN /" tester
BEGIN 1
2
3
$ uname -a
HP-UX labejb B.08.00 B 9000/350 08000902bacf



Note that the sed script specified "starting at line number 1, and
ending at line number 1, substitute the string 'BEGIN ' at the start
of the line".  However, what happened is GNU sed did the substitution
on the first two lines.  This behavior is unexpected and is different
from what the sed on HP-UX 8.0 does.

The following patch appears to fix the problem:

*** sed.c.orig	Fri Sep 25 13:18:49 1992
--- sed.c	Fri Sep 25 14:33:51 1992
***************
*** 504,511 ****
  		}
  		if (   cur_cmd->a1.addr_type == ADDR_NUM
  		    && cur_cmd->a2.addr_type == ADDR_NUM
! 		    && cur_cmd->a2.addr_number <= cur_cmd->a1.addr_number)
! 		  cur_cmd->a2.addr_number = cur_cmd->a1.addr_number+1;
  
  		ch=inchar();
  		if(ch==EOF)
--- 504,511 ----
  		}
  		if (   cur_cmd->a1.addr_type == ADDR_NUM
  		    && cur_cmd->a2.addr_type == ADDR_NUM
! 		    && cur_cmd->a2.addr_number < cur_cmd->a1.addr_number)
! 		  cur_cmd->a2.addr_number = cur_cmd->a1.addr_number;
  
  		ch=inchar();
  		if(ch==EOF)
***************
*** 1062,1068 ****
  		} else if(match_address(&(cur_cmd->a1))) {
  			addr_matched=1;
  			if(cur_cmd->a2.addr_type!=ADDR_NULL)
! 				cur_cmd->aflags|=A1_MATCHED_BIT;
  		}
  		if(cur_cmd->aflags&ADDR_BANG_BIT)
  			addr_matched= !addr_matched;
--- 1062,1069 ----
  		} else if(match_address(&(cur_cmd->a1))) {
  			addr_matched=1;
  			if(cur_cmd->a2.addr_type!=ADDR_NULL)
! 				if(!match_address(&(cur_cmd->a2)))
! 					cur_cmd->aflags|=A1_MATCHED_BIT;
  		}
  		if(cur_cmd->aflags&ADDR_BANG_BIT)
  			addr_matched= !addr_matched;

--
				Eric Backus
				ericb%hplsla@hplabs.hp.com
				(206) 335-2495

Newsgroups: gnu.utils.bug
From: ro@techfak.uni-bielefeld.DE (Rainer Orth)
Subject: sed 1.09 uses wrong regular expression syntax
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 17:11:21 GMT

GNU sed 1.09 uses a wrong syntax for its regular expression. POSIX P1003.2
draft 11.2 section 4.55.7.2 specifies basic regular expressions for sed.

At least sed.c (main) should call re_set_syntax without RE_NO_BK_BRACES,
since /bin/sed on SunOS 4.1.2, SunOS 5.0, and AIX 3.2 all require \{, \}
instead of plain {, } for intervals.  This is also what POSIX specifies for
its basic regular expressions (2.8.3.3 (5)).

===================================================================
RCS file: RCS/sed.c,v
retrieving revision 1.1
diff -u -r1.1 sed.c
--- sed.c	1992/05/23 23:53:56	1.1
+++ sed.c	1992/10/01 15:05:46
@@ -327,7 +327,7 @@
 	struct sed_label *go,*lbl;
 
 	/* see regex.h */
-	re_set_syntax (RE_INTERVALS | RE_NO_BK_BRACES);
+	re_set_syntax (RE_SYNTAX_POSIX_BASIC);
 
 
 	myname=argv[0];

-----------------------------------------------------------------------------
Rainer Orth, Technical Computer Science, University of Bielefeld

Internet: ro@TechFak.Uni-Bielefeld.DE


Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: tar cMff bug
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 00:34:04 GMT

Doing `tar cMff /dev/rfd0 /dev/rfd1 FILES', I get:

Prepare volume #3 for /dev/rfd0 and hit return:
Prepare volume #4 for /dev/rfd1 and hit return:
Prepare volume #5 for /dev/rfd0 and hit return:
[etc.]

I do not get prompted for volume #1 and #2.  On tar versions before
multiple f's, I was never prompted for volume #1 with M.  If one is
supposed to be mounting two volumes to start with, why do not assume
one can mount two volumes at a time afterwards, and not prompt for
even numbered volumes?

My personnal taste, however, is all different.  I would rather be
prompted for *all* volumes with `tar M', even for the first, whatever
one of two f's.  I presume others would rather have no prompt at all.

In any case, could `tar M' prompting be more consistent?  Could the
way it proceeds be made selectable?

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: seth@ctr.columbia.edu (Seth Robertson)
Subject: tar-1.11: No directory chown (report +fix)
Organization: Columbia University Center for Telecommunications Research
Distribution: gnu
Date: Mon, 28 Sep 1992 01:34:03 GMT

My apologies if this has been reported before, but tar is not chowning
the directories to their owner as it creates the directories.  Note
that if tar is trying to extract a file to a directory which does not
exist, my reading of the code indicates that the chown is performed
then.

In any case, here is my fix:

                                        -Seth Robertson
                                         seth@ctr.columbia.edu

--- extract.c.orig	Tue Sep 15 19:54:58 1992
+++ extract.c	Fri Sep 25 06:26:13 1992
@@ -650,6 +650,17 @@
 			  skipcrud+current_file_name);
 		}
 
+#ifndef NODIRCHOWN
+		if (we_are_root || f_do_chown) {
+			 if (chown(skipcrud + current_file_name,
+				   hstat.st_uid, hstat.st_gid) < 0) {
+			   msg_perror("cannot chown file %s to uid %d gid %d",
+				      skipcrud + current_file_name,
+				      hstat.st_uid,hstat.st_gid);
+			 }
+		 }
+#endif
+
 		if (f_modified)
 		  goto set_filestat;
 		tmp = (struct saved_dir_info *) malloc (sizeof (struct saved_dir_info));


Newsgroups: gnu.utils.bug
From: cliff@cs.cornell.edu (Cliff Krumvieda)
Subject: bison-1.19 doesn't build under HP-UX (with fix)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 06:05:18 GMT

Howdy:

I had some trouble building bison-1.19 on an HP 9000/834 running HP-UX
7.00:

======================================================================
gcc -O -c -g  -DSTDC_HEADERS=1 -DUSG=1 -DHAVE_STRERROR=1 -I./../include LR0.c
cc1: warning: `-g' option not supported on this version of GCC
gcc -O -c -g  -DSTDC_HEADERS=1 -DUSG=1 -DHAVE_STRERROR=1 -I./../include allocate.c
cc1: warning: `-g' option not supported on this version of GCC
gcc -O -c -g  -DSTDC_HEADERS=1 -DUSG=1 -DHAVE_STRERROR=1 -I./../include closure.c
cc1: warning: `-g' option not supported on this version of GCC
gcc -O -c -g  -DSTDC_HEADERS=1 -DUSG=1 -DHAVE_STRERROR=1 -I./../include conflicts.c
cc1: warning: `-g' option not supported on this version of GCC
gcc -O -c -g  -DSTDC_HEADERS=1 -DUSG=1 -DHAVE_STRERROR=1 -I./../include derives.c
cc1: warning: `-g' option not supported on this version of GCC
gcc -O -c -g -DXPFILE=\"/usr/local/gnu/bison-1.19/lib/bison.simple\" -DXPFILE1=\"/usr/local/gnu/bison-1.19/lib/bison.hairy\" ./files.c -o files.o
In file included from ./files.c:33:
./system.h:12: strings.h: No such file or directory
make: *** [files.o] Error 1
======================================================================

The problem seems to be that "$(DEFS)" was left out of the rule for
files.o:

======================================================================
files.o: files.c
	$(CC) -c $(CFLAGS) $(PFILES) $(srcdir)/files.c $(OUTPUT_OPTION)
======================================================================

instead of, say:

======================================================================
.c.o:
	$(CC) -c $(CFLAGS) $(CPPFLAGS) $(DEFS) -I$(srcdir)/../include $<
======================================================================

Adding "$(DEFS)" to the files.o rule fixed the problem (system.h,
included by files.c, needed to know that it was being read by a USG
system).

							--Cliff

Newsgroups: gnu.utils.bug
From: howard@hal.com (Howard Gayle)
Subject: GNU make 3.62 core dumps on Solaris 2.0
Reply-To: howard@hal.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 20:40:25 GMT

GNU make 3.62 can core dump on Solaris 2.0 systems if the
following code from read.c (lines 982--988) runs:

	if (!pattern_matches (pattern, pattern_percent, name))
	  {
	    /* Give a warning if the rule is meaningless.  */
	    makefile_error (filename, lineno,
			    "target `%s' doesn't match the target pattern");
	    this = 0;
	  }

The problem is that no argument to makefile_error is supplied
to match the %s format.  So, when fprintf tries to print the
"target `%s' doesn't match the target pattern" string it gets a
random address for the argument corresponding to %s, gets a
SIGSEGV, and core dumps.
--
Howard Gayle
HAL Computer Systems, Inc.
1315 Dell Avenue
Campbell, California 95008
howard@hal.com
Phone: 408-379-7000 ext. 1080
FAX  : 408-379-5022
"Software development, like professional sports, has a way of
making thirty-year-old men feel decrepit."
---Neal Stephenson, Snow Crash, p. 52.

Newsgroups: gnu.utils.bug
From: Derek.BEatty@n3.sp.cs.cmu.edu
Subject: tar 1.11.1 --listed-incremental and --atime-preserve
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 19:06:08 GMT

It appears that at least on my NeXT, if I try to combine these (as the
provided backup scripts do), then the level-1 dump includes everything
accessed since the level-0 dump.  This is not "incremental" because
everything included in the level-0 dump has to be accessed in order
to include it.

 -- Derek

PS: Here's another hint for NeXT floppies: use 
--info-script='/usr/etc/disk -e /dev/rfd0a'.  And if trying to use the
provided backup scripts, add the same command (which ejects the floppy)
at the bottom of the backup-dirs loop, and the bottom of the backup-files
conditional.

Newsgroups: gnu.utils.bug
From: hsu@cs.hut.fi (Heikki Suonsivu)
Subject: xargs
Organization: Helsinki University Of Technology, Otaniemi, Finland
Distribution: gnu
Date: Wed, 7 Oct 1992 02:01:10 GMT

There is xargs supplied with GNU find.  However, it is too good emulating
system V, as it seems to force <500b maximum command line length limit?  I
think most system accept longer argument lists these days, including SunOS
I use?  Could this limitation be moved behind POSIX_ME_HARDER?  Default
could still be whatever it is now?

I looked at the source code, and saw that there was something about
defaults, but couldn't quite figure out where to configure and what to make
it drop the limitation or make it sensible?  Or am I doing something wrong
with the compilation?  If it picks the limit from some OS include file, it
might be a good idea to have a #define FORCE_LONG_ARGUMENTLIST ?

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.


Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Latest GNU versions? [was: GNU tar-1.11 problems]
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 19:51:42 GMT

Michael writes:

   GNU maintainers generally don't have time to figure out which bugs
   have been fixed by the latest release and which have not--so save
   us the trouble, and don't send in bug reports for old versions of
   programs.

It is *preferable* to send bug reports for latest versions, I agree.
However, we should not make this a must.  All bug reports should be
welcome, whatever the version they apply to.

No user should fear reporting problems with GNU products, or feel
forced to fetch and install a new release prior to reporting a bug.
The latest version is not necessarily proven stable, and not all users
have the time to experiment all newest versions.

(And if you accept a tease, many problems reported against tar 1.11
still exist in tar 1.11.1, so it was no point fetching tar 1.11.1 just
for reporting the same problems again... :-).

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: jacobsd@solar.cor2.epa.gov (Dana Jacobsen)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 19:39:43 GMT

  When paste, from textutils-1.3, is given a null delimiter, it core
dumps on our system (Sun Sparcstation, gcc 2.2.2 -O).  This came about
because a user of our system wanted to do "paste -d\\0 f1 f2", but 
hadn't read the man pages fully, so tried "paste -d '' f1 f2" which
core dumps.  When ucb paste is given a null delimiter, it responds
with "paste: no delimiters", but the following patch makes it run as
if it were told to use a null delimiter (that makes more sense to me).



*** paste.c.orig	Thu Jan 16 22:53:10 1992
--- paste.c	Fri Oct  2 12:33:46 1992
***************
*** 104,111 ****
  	{
  	case 'd':
  	  /* Delimiter character(s). */
! 	  if (optarg[0] == '\0')
! 	    optarg = "\\0";
  	  delims = optarg;
  	  break;
  
--- 104,113 ----
  	{
  	case 'd':
  	  /* Delimiter character(s). */
! 	  if (strlen(optarg) == 0) {
! 	    optarg = (char *) xmalloc(2);
! 	    optarg[0] = EMPTY_DELIM;
! 	  }
  	  delims = optarg;
  	  break;
  


--
Dana Jacobsen
jacobsd@solar.cor2.epa.gov
jacobsd@cs.orst.edu
From: patrick@casbs.stanford.edu (Patrick Goebel)
Newsgroups: gnu.utils.bug
Subject: Problwm with gnu finger
Date: 27 Sep 92 18:02:30 GMT
Distribution: gnu
Organization: GNUs Not Usenet

* The Finger version and where you obtained the distribution
casbs% finger .version
GNU Finger server version 1.35, running on casbs.
(from ftp.uu.net, I think)

* Your hardware
Sun 4/330 server (casbs) + 2 SS2 clients (delphi & quercus: both of
which mount /usr/local/etc from the server)

* Operating system
SunOS 4.1.1

* C Compiler used
GNU cc 2.1

PROBLEM: When logging in from our Annex terminal server, or from some
other host on the Internet, the login session is visible only by using
"finger .local".  For example, right now I am logged into casbs from
both our Annex (tip-casbs) and psych.toronto.edu.  Here are the two
finger outputs after giving the finger daemon ample time to note the
logins (at least 10 minutes):

casbs% finger
  User     Real Name         What    Idle  TTY  Host      Console Location
action   Lynn or Patrick            2 days *p3 quercus  (quercus.Stanford)
lynn     Lynn Gale                  2 days *p0 quercus  (:0.0)
patrick  Patrick Goebel              6:48  *p5 quercus  (casbs:0.0)
patrick  Patrick Goebel              6:49  *p0 delphi   (casbs:0.0)

casbs% finger .local
  User     Real Name         What    Idle  TTY  Host      Console Location
action   Lynn or Patrick             6:22  *p3 casbs    (casbs.Stanford.E)
patrick  Patrick Goebel              5:44  *co casbs    unknown
patrick  Patrick Goebel                    *p4 casbs    (tip-casbs.Stanfo)
patrick  Patrick Goebel                    *p5 casbs    (psych.utoronto.c)

Any idea what might be going on?  Many thanks!

--
Patrick Goebel                    E-MAIL: patrick@casbs.Stanford.EDU
Network Administrator             VOICE:  (415) 321-2052
CASBS, 202 Junipero Serra Blvd.   FAX:    (415) 321-1192
Stanford, CA 94305                BEEPER: Temporarily Out of Order...
Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: GNU tar-1.11 problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 10:40:06 GMT

   Resent-Date: Fri, 25 Sep 92 17:56:35 -0600
   Date: Fri, 25 Sep 92 17:56:35 -0600
   From: Bob Proulx <rwp@hprwp.fc.hp.com>
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   Hello GNU tar person!

   I just pulled prep.ai.mit.edu:/pub/gnu/tar-1.11.tar.Z (or something to
   that effect) and compiled it up on a couple of different systems
   (HP-UX and Linux).  For the most part it compiled up easily and ran
   okay.  Good Job!

It is important that people only send in bug reports for the latest
version, in this case, 1.11.1.  GNU maintainers generally don't have
time to figure out which bugs have been fixed by the latest release
and which have not--so save us the trouble, and don't send in bug
reports for old versions of programs.

	-mib

Newsgroups: gnu.utils.bug
From: dror@netcom.com (Oz Dror)
Subject: GNU LD 2.0 for SCO UNIX (i.e., i386-coff)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Tue, 29 Sep 1992 00:50:56 GMT

In Compiling gnu binutils version 2.0 . I found out that SCO unix is not 
supported for the ld program. (i.e., there is no support for i386-coff),
But it is mentioned in the manual. There is also support for in the BFD
library.
I think that only the script file is missing.

Dose anyone have any idea how to solve this problem?

My system is: 486/50Mhz
OS: SCO Unix (3.2.2, ODT1.1)

I would appreciate any help?
Thanks,

-- 
NAME   Oz Dror
SMAIL  dror@netcom.com
PHONE  (213) 874-7978  Fax (213) 667-6908

Newsgroups: gnu.utils.bug