HDTenEightyP/NetNews huggingface dataset:
From: jesmith%gdfwc3@sun.com (Jesse Smith)
Subject: glibc-1.05 zic problems on sparc-sun-sunos4.1
Organization: General Dynamics, Fort Worth Division
Distribution: gnu
Date: Sun, 4 Oct 1992 17:33:02 GMT

I got all of glibc-1.05 compiled fine on my Sparc 2 running SunOS 4.1.1.
The "make install", however, blows up when you first try to run "zic".
Zic aborts with a Segmentation fault.  Same thing happens if you
try to run zic by hand with any or no command line parameters (as far
as I can tell).

BTW, whether or not I used --with-gnu-as and/or --with-gnu-ld seemed to
make no difference.

Has anyone else seen this behavior and have a solution?  Please post or
reply to the email address below.

Thanks!
Jesse Smith
smith@riogrande.cs.tcu.edu

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: gas on Sequent Symmetry?
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sat, 26 Sep 1992 10:30:42 GMT

Has anyone gotten gas 1.38.1 working properly on a Sequent Symmetry running
Dynix?  As distributed, it won't even build on the Symmetry, because of the
missing a_version field in the gas definition of struct exec.  We have a
patch here which will convince the program to build and run, but using it
with GCC 2.2.2 produces programs that seg fault rather than doing anything
useful.

Any pointers would be appreciated.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.utils.bug
From: davison@blueridge.UUCP (Mike Davison)
Subject: Undocumented error/warning from objcopy for i960
Organization: FiberCom, Inc., Roanoke, Virginia
Distribution: gnu
Date: Mon, 28 Sep 1992 14:24:06 GMT

I get an error/warning from objcopy from the i960 version of the 
Intel-modified gnu utilities and cannot determine if this is 
really a problem. The code loads and runs fine. The command and the 
error/warning are shown below:

objcopy -q -l foo.o
bfd assertion fail b.out.c:575
bfd assertion fail b.out.c:575
< repeats many times>

I would assume that "bfd" means binary file desriptor and
that b.out.c:575 is the file name and line number at which this 
assertion was made. Now, what does it mean? Any comments?

Thanks,
Mike

-- 
--
Michael Davison            |  internet: davison@fibercom.com
FiberCom, Inc.             |  voice:    (703) 342-6700, extension 349
Roanoke, VA 24022-1966     |  fax:      (703) 342-5961

Newsgroups: gnu.utils.bug
From: lwv26@cas.ORG (Larry W. Virden, x2487)
Subject: Problem in shellutils 1.7 on SunOS 4.1.2 and gcc 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 14:55:42 GMT

When I try to build shellutils 1.7 on a SS 1+, SunOS 4.1.2, gcc 2.2.2 I
get the following errors:

gcc -O -c -g  -DHAVE_LIMITS_H=1 -DHAVE_SYSLOG_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_FTIME=1 -DHAVE_UT_HOST=1 -DHAVE_C_LINE=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_TM_ZONE=1 -DDIRENT=1 -I. strtoul.c
In file included from /projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:10, from ./strtol.c:33, from strtoul.c:21:
/usr/include/sys/stdtypes.h:27: redefinition of `size_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:82: `size_t' previously declared here
/usr/include/sys/stdtypes.h:28: redefinition of `ptrdiff_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:45: `ptrdiff_t' previously declared here
/usr/include/sys/stdtypes.h:30: redefinition of `wchar_t'
/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:120: `wchar_t' previously declared here
gmake[1]: *** [strtoul.o] Error 1


Does anyone know what the problem might be?
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: tar 1.11.1 installation report (sort of)
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 21:05:00 GMT

This reports an `hurry' installation of GNU tar 1.11.1 on a recent
ESIX system (System V R4 flavor, I do not know which version), while
passing nearby.  I'm away now.  This slightly fuzzy report is repeated
from hastily written notes.  The problems were real, however.

* I needed to put -Dconst= to get it to compile, as a kludge.
Somewhere, some system include files define prototypes, using const.
Then, a tar include file defines const as empty.  Finally, further
system files are included which have consistent redeclarations of
prototypes, but since const is now empty, these redeclarations produce
compilation errors.  const should rather not be defined to empty for
this system.

* In Makefile.in, ALLOCA = @ALLOCA@ is missing, as well as $(ALLOCA)
in the load object list.

* msg("cound only write %d of %d bytes to file %s\n", ...) appears two
times in extract.c.  I think that in both cases, the argument list is
incorrect.  The first time, written and check are reversed.  The
second time, `totalsize - *sizeleft' cannot be good, the value
returned by the write call should be used somewhere.  The user problem
triggering the diagnostic was a too small ulimit.

* `tar tfvz FILE.tar.Z' (and `tar x...' too) sometimes (maybe for 3
out of 15 archive files) produces, after having processed many files,
almost all, maybe all, the quite unexpected diagnostic:

	write error onstdout: I/O error

There was no space between `on' and `stdout'.  For all cases, stdout
was not redirected.  The problem was repeatable while I was there on a
file by file basis, that is, when a file was getting tar to fail with
this diagnostic, the file was always getting tar to fail.

-- 
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: DALL@hfrd.dsto.gov.au
Subject: GAS problems for the 32x32
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 21:35:42 GMT

I was adding some debugging code to the mach UX server and concluded that
the assembler doesn't handle pc relative addressing properly under
some circumstances. The following code


char *string;

main()
{
  string = "The Quick Brown Fox";
  printf("%s\n", string);
}


core dumps when compiled with gcc 2.2.2 (which generates pc relative
addressing by preference) and assembled with gas 1.38.1.

I have looked at gas and I think I can see what goes wrong. It doesn't
get the pcrel_adjust field correct in the second operand unless the
first operand displacement is known when frags get generated (in
convert_iif) or ends up 4 bytes big after all the relaxation etc.

This is difficult to fix because the pcrel_adjust is really a kludge
to try and make a 68020 assembler work for the 32x32 (which does its
displacements from the address of the instruction instead of the
address of the displacement)! The required value for pcrel_adjust is
essentially the size of the instruction so far. Unfortunately, the
size of the instruction so far is indeterminate at the time the
pcrel_adjust field is calculated and may be affected by the relax
phase. Further, the the pcrel_adjust field is also used in fix's
(which, I think, are required for relocation information).

The only way I can see (keeping the structure of gas the same) to fix
this is to keep track of when a new instruction starts (or the first
new frag after a new instruction starts) (needs an extra field in
frag), notice how much stretching happens within an instruction, and
adjust the pcrel adjustment by that amount. Also remember (in some
auxilary structure) which frags have had their adjustments adjusted
and by how much. Use this auxilliary info to fix the fix's. Maybe
fixes could just use the pcrel_adjust field in the frag instead of
their own pcrel_adjust field.

This is all a tangled mess. Maybe someone has fixed it?

If anyone can compile the above program with gcc 2 and gas for the 532
and run it, I would be very interested in whatever gas magic you are
using.

Ian


Newsgroups: gnu.utils.bug
From: mellon@pepper.UUCP (Ted Lemon)
Subject: Variable redefinition using += in GNU Make...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 22:58:21 GMT

I'm trying to use GNU Make on some of our makefiles internally, but
I find that we use a feature present in 4.3-Tahoe and SunOS make,
which is that you can add stuff to the end of a variable definition by
using a += operator; e.g.,

FOO = bar
FOO += baz

Would result in foo being set to ``bar baz''.   I notice that this
functionality is implemented differently in GNU make - a := operator
has been introduced which evaluates the RHS before assigning to the
LHS (I'm not entirely clear on how this works, but I'm sure it will be
evident when I spend a little time playing with it).

The problem is this: I am now stuck with having to choose which
implementation to support - GNU Make doesn't support the += construct,
and SunOS/BSD Make doesn't support the := construct.   Does anybody
have any plans to do anything about this, or am I putting my foot in a
religious debate by bringing this up?

			       _MelloN_
--
[Dan Quayle is] my choice, my first choice, and my only choice.
                -- President George Bush

Newsgroups: gnu.utils.bug
From: neal@ctd.COMsat.COM (Neal Becker)
Subject: Re: patch-2.012g8 for HP
Organization: COMSAT Labs
Distribution: gnu
Date: Mon, 28 Sep 1992 12:34:07 GMT

This is caused by -lPW brain damage.  You just need -lPW for alloca.
Just either
1) extract alloca.o from libPW.a and make youself a
/usr/local/lib/liballoca.a or
2) use alloca.c

Newsgroups: gnu.utils.bug
From: pinard@iro.umontreal.CA (Francois Pinard)
Subject: find-3.7 configure program
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 13:54:29 GMT

   There is no way in the configure switches to set the binprefix and
   manprefix variables.  I would assume there should be so you don't
   have to edit the Makefile.in.

The INSTALL document suggests editing Makefile after configure for
adjusting those definitions.  Personnaly, I do it at make time:

	make install binprefix=... manprefix=...

Even if this is not written anywhere (so far that I know), I got the
feeling that upper case definitions are meant to be adjusted by
configure, while lower case ones are meant to be adjusted `manually'.

-- 
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: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: tar 1.11.1 --listed-incremental with --atime-preserve
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 09:39:01 GMT

   Resent-Date: Wed, 30 Sep 1992 14:35:22 -0400 (EDT)
   Date: Wed, 30 Sep 1992 14:35:22 -0400 (EDT)
   From: Derek Beatty <beatty@cs.cmu.edu>
   Sender: gnulists@ai.mit.edu
   Mime-Version: 1.0
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   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.

That is correct.  There is a lossage, which is unavoidable, sort of.
The work around is for --atime-preserve to read the disk device
directly.  That will be done in 1.12.  Until then, remove
--atime-preserve from the backup scripts.

	-mib

Newsgroups: gnu.utils.bug
From: ro@techfak.uni-bielefeld.DE (Rainer Orth)
Subject: fileutils 3.3.1 bug on Solaris 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 03:35:06 GMT

When configuring fileutils 3.3.1 on Solaris 2.0, configure fails to
recognize that the SVR4 functions to get the list of mounted filesystems
are available.  This happens because it searches for putmntent in
<sys/mnttab.h> after that file has passed the C preprocessor.
Unfortunately, putmntent is a macro in SunOS 5.0 and cannot be found.  It
seems to be safer to check for getmntent instead, which seems always to be
a function.

===================================================================
RCS file: RCS/configure,v
retrieving revision 1.1
diff -u -r1.1 configure
--- configure	1992/08/21 22:01:27	1.1
+++ configure	1992/10/02 01:21:16
@@ -345,7 +345,7 @@
 # SVR4
 echo '#include <sys/mnttab.h>' > conftest.c
 eval "$CPP $DEFS conftest.c > conftest.out 2>&1"
-if egrep "putmntent" conftest.out >/dev/null 2>&1; then
+if egrep "getmntent" conftest.out >/dev/null 2>&1; then
   DEFS="$DEFS -DMOUNTED_GETMNTENT2=1" mounted=1
 fi
 rm -f conftest*
 
-----------------------------------------------------------------------------
Rainer Orth, Technical Computer Science, University of Bielefeld

Internet: ro@TechFak.Uni-Bielefeld.DE


Newsgroups: gnu.utils.bug
From: jsr@dit.upm.ES (Joaquin Salvachua)
Subject: error with HP
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 17:43:09 GMT

 I'm posting it for a friend, reply to my adress
-------------------
	I'm a poor root that suffers of an HP-9000/380 with HP-UX 8.0 . Few 
days ago, I got the tapes from FSF , loaded them on the HP and try to compile..
( the manuals say that every things go well ...with version 7.0... ) but not
with a newer version.
	Especifically, 
	- I cannot compile ranlib ( $(DISTPATH)/binutils-1.9/ )
		_psignal, _xmalloc undefined
	- hpxt compiles but fails in running ( $(DISTPATH)/binutils-1.9/hp-bin )
		hpxt: illegal relocation segment type: 4       (sometimes 3f)
		IOT trap (core dumped)
Due to the fact that I need these two programs in order to compile GCC and G++
using GAS ( to enable the use of GDB ) I cannot make a full installation of the
FSF software
  Can anyone help me to do the work? Where can I get the patches for HP-UX 8.0?
  Moreover: is there a posibility to obtain sources for X11R5 server for my HP
( they are not included in mit tapes )
	Thanks in advance
		Juan A. Martinez
-----------------------------------------------------------
Joaquin Salvachua               tel: +34 1 549 57 00  x.367
                                     +34 1 549 57 62  x.367
dpt. Telematica                            
E.T.S.I. Telecomunicacion 
Ciudad Universitaria            fax: +34 1 543 20 77
E-28040  MADRID                 tlx: 47430 ETSIT E
SPAIN

E-mail:        jsalvachua@dit.upm.es
Alternatives:  jsalvachua@goya.uucp

k

Newsgroups: gnu.utils.bug
From: ro@techfak.uni-bielefeld.DE (Rainer Orth)
Subject: gdbm 1.5 changes for Solaris 2.0/SVR4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 03:04:16 GMT

Below I've included the few changes I had to make to gdbm 1.5 to have it
compile and pass the tests in the native SVR4 environment of Solaris 2.0,
using gcc 2.2.2 ss-920925.

===================================================================
RCS file: RCS/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- Makefile	1991/01/24 17:22:59	1.1
+++ Makefile	1992/09/30 20:38:41
@@ -7,11 +7,11 @@
 #
 # for gcc, uncomment the CC = gcc line.
 
-#CC = gcc
-CFLAGS = -g # -O -DSYSV
+CC = gcc
+CFLAGS = -g -O -DSYSV -DSVR4
 LDFLAGS =
 LIBS = # -lPW
-DBM = -ldbm
+DBM = -L/usr/ucblib -ldbm -lucb
 NDBM = -lc
 LIBC = -lc
 LINTFLAGS =
===================================================================
RCS file: RCS/systems.h,v
retrieving revision 1.1
diff -u -r1.1 systems.h
--- systems.h	1991/03/01 00:58:34	1.1
+++ systems.h	1992/09/30 20:28:21
@@ -36,6 +36,7 @@
 
 /* File seeking needs L_SET defined .*/
 #include <unistd.h>
+#undef L_SET
 #define L_SET SEEK_SET
 
 /* Some files need fcntl.h for locking. */
@@ -70,7 +71,13 @@
 #define bcmp(d1, d2, n)	memcmp(d1, d2, n)
 #define bcopy(d1, d2, n) memcpy(d2, d1, n)
 
-/* Sys V does not have fsync. */
+/* Get string definitions. */
+#include <string.h>
+#define _HAVE_STRING
+#endif
+
+#ifndef SVR4
+/* Sys V before R4 does not have fsync. */
 #define fsync(f) sync(); sync()
 
 /* Stat does not have a st_blksize field. */
@@ -79,13 +86,9 @@
 /* Does not have rename(). */
 #define NEED_RENAME
 
-/* Get string definitions. */
-#include <string.h>
-#define _HAVE_STRING
-#endif
-
-/* Sys V does not have a truncate call, how primitive. */
+/* Sys V before R4 does not have a truncate call, how primitive. */
 #define TRUNCATE(dbf) close( open (dbf->name, O_RDWR|O_TRUNC, mode));
+#endif
 
 
 /*      End of System V changes and defines.      */

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

Internet: ro@TechFak.Uni-Bielefeld.DE



Newsgroups: gnu.utils.bug
From: qtanaka@cs.uec.ac.JP (TANAKA Satoshi)
Subject: finger-1.35 bug report.
Reply-To: qtanaka@cs.uec.ac.jp (TANAKA Satoshi)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 02:01:45 GMT

* Title
GNU finger-1.35 Bug Report.

* Changes
The Variable "time_between_polls" has a "volatile" quantifier.

* Reasons
ANSI C requirements.
After longjmp(3), a "non-volatile" variables has unpredictable value,
because of register assignment.

* The Finger version and where you obtained the distribution
GNU finger version 1.35 from sh.wide.ad.jp

* Your hardware
SONY RISC-NEWS 3460

* Operating system
NEWS-OS Release 4.1R #0: Fri Jul  5 16:44:29 JST 1991

* C Compiler used
@(#)MIPS RISCompiler 2.11 (from NEWS-OS 4.0R) Sat Jun 29 22:02:06 JST 1991

* Your network configuration; don't forget to mention what
  hardware, operating systems, and C compilers are used on each
  node where the bug manifests itself.
No relation.

* Patches if you have any
*** src/fingerd.c	Wed Sep 30 15:27:39 1992
--- src/fingerd.c.orig	Tue Aug 25 03:25:31 1992
***************
*** 74,82 ****
  char *hoststat;
  
  /* The amount of time (in seconds) we sleep between each poll. */
- #if __STDC__
- volatile
- #endif
  int time_between_polls = 120;
  
  /* The number of machines polled each time. */
--- 74,79 ----

* Anything else you think is relevant
Nothing.


$@EDCf(J $@Ao(J
TANAKA Satoshi
qtanaka@cs.uec.ac.jp 

------- End of Blind-Carbon-Copy


Newsgroups: gnu.utils.bug
From: gsk@marble.COM (Geoffrey S. Knauth)
Subject: (1.18) bison.info, node "Mid-Rule Actions"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 14:55:33 GMT

2nd line below, "can referred to" should be "can be referred to"

>    The mid-rule action can also have a semantic value.  This can be set
> within that action by an assignment to `$$', and can referred to by
> actions later in the rule using `$N'.  Since there is no symbol to

Newsgroups: gnu.utils.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Bugs in indent 1.6
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 14:47:01 GMT

There are (atleast :-) three bugs in indent 1.6:

* args.c (struct pro pro, !BERKLEY_DEFAULTS): default values for -fc1
and -nfc1 doesn't correspondent with the -gnu setting

* io.c (read_stdin): pointer into stdinptr.data must be relocated each
time stdinptr.data is reallocated

* indent.c (indent):
`sizeof (char)' is read by `lexi' as ident, lparen, decl, rparen in the
following example (`decl' should be `ident', i think):
----------- test.c
f ()
{
  do
    g ();
  while (sizeof (char));
}
----------

Output of: indent test.c -st
----------
f ()
{
  do
    g ();
  while (sizeof (char));
/**INDENT** Error@6: Stmt nesting error. */
  }
/**INDENT** Error@7: Stuff missing from end of file. */
----------
With the patch in indent.c this error disappears.


diff -u2r orig/args.c ./args.c
--- orig/args.c	Mon Aug 10 21:32:22 1992
+++ ./args.c	Tue Aug 25 20:56:20 1992
@@ -317,5 +317,5 @@
   {"fbx", PRO_FONT, 0, ONOFF_NA, (int *) &boxcomf, &exp_fbx},
   {"fb", PRO_FONT, 0, ONOFF_NA, (int *) &bodyf, &exp_fb},
-  {"fc1", PRO_BOOL, true, ON, &format_col1_comments, &exp_fc1},
+  {"fc1", PRO_BOOL, false, ON, &format_col1_comments, &exp_fc1},
   {"fca", PRO_BOOL, false, ON, &format_comments, &exp_fca},
   {"fc", PRO_FONT, 0, ONOFF_NA, (int *) &scomf, &exp_fc},
@@ -354,5 +354,5 @@
   {"neei", PRO_BOOL, false, OFF, &extra_expression_indent, &exp_eei},
   {"nei", PRO_BOOL, true, OFF, &else_if, &exp_ei},
-  {"nfc1", PRO_BOOL, true, OFF, &format_col1_comments, &exp_fc1},
+  {"nfc1", PRO_BOOL, false, OFF, &format_col1_comments, &exp_fc1},
   {"nfca", PRO_BOOL, false, OFF, &format_comments, &exp_fca},
   {"nip", PRO_SETTINGS, 0, ONOFF_NA, (int *) "-ip0\0", &exp_nip},
diff -u2r orig/indent.c ./indent.c
--- orig/indent.c	Wed Aug 19 23:32:28 1992
+++ ./indent.c	Sat Oct  3 16:23:58 1992
@@ -573,4 +573,5 @@
 	  if (parser_state_tos->last_token == decl
 	      || (parser_state_tos->last_token == ident
+		  && parser_state_tos->last_rw != rw_sizeof
 		  && parser_state_tos->last_rw != rw_return))
 	    parser_state_tos->noncast_mask |=
diff -u2r orig/io.c ./io.c
--- orig/io.c	Sat Aug 15 00:09:16 1992
+++ ./io.c	Tue Aug 25 21:32:58 1992
@@ -488,7 +488,7 @@
   stdinptr.data = (char *) xmalloc (size + 1);
   stdinptr.size = 0;
-  p = stdinptr.data;
   do
     {
+      p = stdinptr.data + stdinptr.size;
       while (stdinptr.size < size)
 	{
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.utils.bug