HDTenEightyP/NetNews huggingface dataset:
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Attaching to a process
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Thu, 19 Nov 1992 14:38:19 GMT

I'm using gdb-4.7 on sunOS 4.1.2.

When I do gdb +help, it says:
This is GDB, the GNU debugger.  Use the command
    gdb [options] [executable [core-file]]
to enter the debugger.

It would be nice if there was a version there.

The arguments to gdb don't include a PID.

I did this:
	ps | fgrep tin
	 7116 p7 S     0:01 xterm -title tin-debug -e bash
	 7122 p8 S     0:01 xterm -title tin -e tin
	 7187 p8 S     0:00 fgrep tin
	 7123 p9 IW    0:01 tin
	leisner@annapurna$ gdb /usr/marty/bin/tin 7123
	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.7, Copyright 1992 Free Software Foundation, Inc...

	/files3/leisner/src/tin-1.17/7123: No such file or directory.

	Can't attach to a process on this machine.

How do I attach to a process? 


--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.utils.bug
From: dao@abars.ATt.COM (David A Oshinsky)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 22:03:37 GMT

This is to report a bug in gnu cpio version 2.1.  The bug is as follows:

When gnu cpio 2.1 reads an old-style (short header) binary cpio file,
it does not read the proper c_dev and c_ino fields into the new cpio
header.  This can cause serious problems since cpio bases the decision
to create hard links (for those files with nlinks > 1) on the values of
the c_ino field.

The following patch, when applied to copyin.c, fixes the bug (changes are
made in the read_in_binary() function):

217c217
<    number), which are already filled in.  */
---
>    number), which are already filled in.
218a219,223
>    Note AT&T DAO 11/16/92: above comment is inaccurate since the first 6
>    bytes of the short binary header includes the magic number, device number,
>    and the inode number (not just the magic number !!!!).
> */
> 
241a247,251
> 
>   /* AT&T DAO 11/16/92 to fix a SERIOUS bug:  initialize c_dev and	*/
>   /* c_ino fields of short_hdr (from bytes 3 through 6 of file_hdr) !!! */
>   short_hdr.c_dev = ((struct old_cpio_header *)file_hdr)->c_dev;
>   short_hdr.c_ino = ((struct old_cpio_header *)file_hdr)->c_ino;


		David Oshinsky
		AT&T
		uucp: att!abars!dao
		phone: (908)870-7693

Newsgroups: gnu.utils.bug
From: gnu@cygnus.com
Subject: Exit Status Codes for GNU TAR
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 02:49:26 GMT

GNU Tar is based on my old "pdtar" program, but it is about five years
further evolved.  The right address for your message is
bug-gnu-utils@prep.ai.mit.edu.  You can also read the newsgroup
gnu.utils.bug, which is pretty much the same thing.

	John Gilmore

------- Forwarded Message

From: plarkin@iphase.com (Patrick Larkin)
Message-Id: <9211201401.AA25390@coolcat.iphase.com>
Subject: Exit Status Codes for GNU TAR
To: gnu@cygnus.com
Date: Fri, 20 Nov 92 8:01:36 CST
Cc: tdawson@coolcat.iphase.com (Tim Dawson),
        plarkin@coolcat.iphase.com (Patrick Larkin)

Well guys (& gals),  I've inherited a system that uses your 'tar' command.
I've searched many MAN pages, rooted through the gnu tar source and
examined "The tar Manual: DRAFT" and cant find a defininition of the
exit status codes for gnu tar.

I know 2 of them:  3=end of media or tape drive not-ready (OFFLINE, WPRT, etc)
and '137' is acheived by executing a 'kill' on the process.  What 
"scares" me is when I get an exit status of "32781".

Please send me a list of the exit status codes and their definitions,
or point me to the right system MAN pages (if you're getting them elsewhere)

Also, Is there a newsgroup I should follow?

(trying to setup guidlines for a non-tech to run our backups & do 
minor problem diagnosis/recovery)

Thanks so much - In advance - for your help,
-- 
__________________________________________________________________
   Patrick H. Larkin, Jr.              Interphase Corp.      
    System Administrator                13800 Senlac 
       (214) 919-9362                   Dallas, TX 75234-8823 
     plarkin@iphase.com                 Fax: (214)919-9200
------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: scjones@thor.sdrc.com (Larry Jones)
Subject: Patch bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 07:55:25 GMT

Patch has a problem patching a read-only file with a 14
character name on a file system that only supports 14 character
names.  Since the file is read-only, patch tries to find an RCS
or SCCS file to check out.  Unfortunately, the generated RCS
file name, when truncated to 14 characters, is the same as the
original file name so patch thinks it has found an RCS file and
tries to do RCS stuff which then fails.  The following diff
(against the 12u8 version) fixes this problem by checking that
the RCS file is not the same as the original file before trying
to process it.

*** inp.c.old	Thu Nov 19 12:04:18 1992
--- inp.c	Thu Nov 19 12:06:02 1992
***************
*** 109,117 ****
  	strncpy(s, filename, pathlen);
  
  #define try(f, a1, a2) (Sprintf(s + pathlen, f, a1, a2), stat(s, &cstat) == 0)
! 	if (   try("RCS/%s%s", filebase, RCSSUFFIX)
! 	    || try("RCS/%s"  , filebase,         0)
! 	    || try(    "%s%s", filebase, RCSSUFFIX)) {
  	    Sprintf(buf, CHECKOUT, filename);
  	    Sprintf(lbuf, RCSDIFF, filename);
  	    cs = "RCS";
--- 109,119 ----
  	strncpy(s, filename, pathlen);
  
  #define try(f, a1, a2) (Sprintf(s + pathlen, f, a1, a2), stat(s, &cstat) == 0)
! 	if ((   try("RCS/%s%s", filebase, RCSSUFFIX)
! 	     || try("RCS/%s"  , filebase,         0)
! 	     || try(    "%s%s", filebase, RCSSUFFIX)) &&
! 	    (   filestat.st_dev != cstat.st_dev
! 	     || filestat.st_ino != cstat.st_ino)) {
  	    Sprintf(buf, CHECKOUT, filename);
  	    Sprintf(lbuf, RCSDIFF, filename);
  	    cs = "RCS";
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Hmm... That might not be politic. -- Calvin

Newsgroups: gnu.utils.bug
From: ecprest@pocorvares.er.usgs.gov (Eric Prestemon)
Subject: fontutils 0.5 X-related bug(?)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 07:16:25 GMT

Using xbfe 0.5, the program dies with the following:
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  67 (X_PolyRectangle)
  Serial number of failed request:  10159
  Current serial number in output stream:  10160

The problem occurs when I click button1, and then move the cursor
(i.e. when AdjustSelection is triggered.) I did not install X here,
and know little about X, so I don't know if this is an X problem or a
GNU problem. I have tried compiling xbfe with gcc 2.3.1 and the older
version of gcc installed here which reports itself as:
gcc version 1.96 (88open OCS/BCS, DG-1.96.4, Jan 17 1992)

I am on a DGUX 5.4.1 Aviion workstation, using X11R4 (compiled with I
don't know what)
This happens no matter what font file I try to edit.

Is this an X error or an Xbfe problem? If it is an X error, where can
I look to find out how to fix it/work around it?

Thanks for any help, 
Eric

Newsgroups: gnu.utils.bug
From: dembo@csri.toronto.edu (Prof. Ron Dembo)
Subject: Bunutils-2.0 version of ar on a decstation?
Keywords: ar decstation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 13:40:34 GMT

I am happily using binutils-2.0 version of ar and ld on a sparc
running 4.1.3 and I'd like to move my environment over to a
Dec 5000/240 running ultrix 4.3.  Gcc and gdb are running no problem.
However,  I can't get ar to produce a working version.  The configuration
script doesn't produce a makefile in the binutils subdirectory.  After
hande compiling ar use the Makefile.in I get a version of ar that runs
but produces archive files that consist of the ascii line
!<arch>

Any ideas?
	Thanks in advance

Newsgroups: gnu.utils.bug
From: osyjm@cs.montana.edu (Jaye Mathisen)
Subject: CVS problems -- More of a usage problem
Organization: CS
Distribution: gnu
Date: Mon, 16 Nov 1992 00:54:15 GMT

It could be that I'm just flat out confused here...  So bear with me.

I've installed cvs-1.3 on an HP 9000/730 (8.05), and a Decstation 5000/240
(Ultrix 4.3).

I took and converted my GNU source tree to CVS.

I tagged (rtag actually) the  initial release of the source as 'BASELINE' 
(missed the part about BASE apparently).

Then I went and tagged the source with a few tags, ala' (Using diff-1.15
as an example)

cvs rtag -b TAG1 diff-1.15
cvs rtag -b TAG2 diff-1.15

Where TAG1 and TAG2 are 2 architecture dependent flags.

On the decstation, I can do a cvs checkout -r TAG1 diff-1.15
and it creates the dir, just like it's supposed to, and lets me  edit/update
, commit, etc.  just like it should.

So now I bop over to the HP, and I want to build diff-1.15 for it:

erchp2:/P#/Gnu-dev/src % cvs checkout -r $CVSTAG diff-1.15 
cvs checkout: Updating diff-1.15
erchp2:/P#/Gnu-dev/src % ls
diff-1.15/
erchp2:/P#/Gnu-dev/src % ls -R
diff-1.15/

./diff-1.15:
CVS/

./diff-1.15/CVS:
Entries      Repository   Tag


And no files... Argh.  I jump back over to the decstation, and do the
same command, and it works.


Any speculation?  byte-order problems?  Bizarro weirdness in the HPUX
supplied versions of ci/co?
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@cs.montana.edu

Newsgroups: gnu.utils.bug
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Oleo STILL fails to resolve _main during link
Organization: GMI Engineering&Management Institute, Flint, MI
Distribution: gnu
Date: Fri, 20 Nov 1992 11:45:06 GMT

I posted a few days ago that after getting past all of the compile-time
errors in oleo, that it now fails to resolve _main at linktime.  I have
grep'ed through the source and am convinced that there is one and only one
main() in the scope of the preprocessor pass, in io_term.c.  I recompiled
this module and tried to relink, no difference.

I may be overlooking something obvious.  I am compiling with GCC 2.3.1.  I
have added the preprocessor test on defined(sun) in one of the modules to
prevent the asm call, and I have set CFLAGS to include -D__STDC__ to avoid
some sections with old-style varargs.  I am also using -fpcc-struct-return.

Any help?


--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /

Newsgroups: gnu.utils.bug
From: nico@bredex.DE (Nico Josuttis)
Subject: REGEX: fatal BUG in regex.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 15:32:03 GMT

Hi folks,
i found a fatal bug using ranges and translate tables
(regex 0.11).

Scenario:
  Pattern: [A-A]
  String:  A
  => OK, (match value: 1)

  BUT: Pattern: [a-a]
       String:  a
       => ERROR, NO MATCH

That happens when i use the translate table "upcase".

IMHO the bug is the following:
In regex.c in compile_range() in line 2181:
	PATFETCH (range_end);
must be
	PATFETCH_RAW (range_end);
because otherwise a translated char gets compared with
a non translated char.
In my example this processes the range [a-A], which is empty.

Hope this helps.

BTW, is there a list with any other open bugs ?

--------
Nico
                                 address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Kastanienallee 2a 
phone:   +49 531 75480                    D-3300 Braunschweig
fax:     +49 531 796358                   Germany
--------

Newsgroups: gnu.utils.bug
From: GSCOTT@manvm1.vnet.ibm.COM
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 03:59:22 GMT

This problem is with make 3.62 running on AIX 3.2.2

Problem:  improper expansion of "$<" when using the following makefile.

---

CC = gcc
CFLAGS = -g -Wall
LIBS = -lm
PROG = lfa_null

OBJS = lfan_main.o lfan_track.o lfan_bf.o tb_bf.o
SOURCES = lfan_main.c lfan_track.c lfan_bf.c tb_bf.c
INCLUDES = lfa_null.h tb.h

all: $(PROG)

$(PROG): $(OBJS)
	$(CC) $(CFLAGS) -o $@ $(OBJS) $(LIBS)

$(OBJS): $(SOURCES) $(INCLUDES)
	$(CC) $(CFLAGS) -c $<

---

Below is a script illustrating the problem.
/bin/make is the default AIX make
/usr/local/gnu/make is gnu make 3.62

---

$ /bin/make -n

gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_track.c
gcc -g -Wall -c lfan_bf.c
gcc -g -Wall -c tb_bf.c
gcc -g -Wall -o lfa_null lfan_main.o lfan_track.o lfan_bf.o tb_bf.o -lm

$ /usr/local/gnu/make -n

gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -o lfa_null lfan_main.o lfan_track.o lfan_bf.o tb_bf.o -lm

---

Below is a script of what happens when the files must be retrieved
with RCS.  Note, it retrieves all of the correct files, but still only
tries to compile the first file in OBJS

---

$ /usr/local/gnu/make -n

test -f lfan_main.c || co  RCS/lfan_main.c,v lfan_main.c
test -f lfan_track.c || co  RCS/lfan_track.c,v lfan_track.c
test -f lfan_bf.c || co  RCS/lfan_bf.c,v lfan_bf.c
test -f tb_bf.c || co  RCS/tb_bf.c,v tb_bf.c
test -f lfa_null.h || co  RCS/lfa_null.h,v lfa_null.h
test -f tb.h || co  RCS/tb.h,v tb.h
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall -c lfan_main.c
gcc -g -Wall  -o lfa_null lfan_main.o lfan_track.o lfan_bf.o tb_bf.o -lm

---

George Scott
gms2@po.cwru.edu
gscott@manvm1.vnet.ibm.com


Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Difference in sort
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 20 Nov 1992 15:13:59 GMT

I'm running sort (from textutils version 1.3) on SunOS Sparcs 4.1.2...

The options are very different then the one on the sun...I don't have
a posix spec around...most of the time the GNU utilities are
better...

>From the sun:
NAME
       sort - sort and collate lines

SYNOPSIS
       sort  [  -bdfiMnr  ]  [ -tc ] [ sort-field ...] [ -cmu ] [
       -o[ ]output-file ] [ -T directory ]
        [ -y kmem ] [ -z recsz ] filename...

SYSTEM V SYNOPSIS
       /usr/5bin/sort [ -bdfiMnr ] [ -tc ] [  sort-field  ...]  [
       -cmu ] [ -o[ ]output-file ] [ -T directory ] [ -y kmem ] [
       -z recsz ] filename...

>From gnu:
NAME
       sort - sort lines of text files

SYNOPSIS
       sort  [-cmus]  [-t  separator] [-o output-file] [-bdfiMnr]
       [+POS1 [-POS2]] [-k POS1[,POS2]] [file...]

This is a problem because I'm running indxbib and it returns:
cognized option `-T'
Usage: sort [-cmus] [-t separator] [-o output-file] [-bdfiMnr] [+POS1 [-POS2]]
       [-k POS1[,POS2]] [file...]

(I got around this by putting /usr/bin in front of my path)

What does posix say?

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.utils.bug
From: conklin@talisman.kaleida.com (J.T. Conklin)
Subject: memory leak in gnu make 3.62
Reply-To: conklin@kaleida.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 23:24:10 GMT

The following patch allocates storage on the stack in the DIRONLY
macro, rather than using the savestring function().  The macro is
a tiny bit uglier, but it doesn't waste memory.

Performance should not suffer since good compilers will recognize that
"(p - (s))" is a common subexpression.

diff -c make/commands.c:1.1.1.1 make/commands.c:1.3
*** make/commands.c:1.1.1.1	Mon Nov 16 15:12:56 1992
--- make/commands.c	Mon Nov 16 15:12:56 1992
***************
*** 65,71 ****
  #define	LASTSLASH(s)	rindex ((s), '/')
  #define	FILEONLY(s)	(p != 0 ? p + 1 : (s))
  #define	DIRONLY(s)	(p == 0 ? "./" : p == (s) ? "/" \
! 			 : savestring ((s), (p - (s)) + 1))
  
    /* $* is the stem from an implicit or static pattern rule.  */
    if (file->stem == 0)
--- 65,71 ----
  #define	LASTSLASH(s)	rindex ((s), '/')
  #define	FILEONLY(s)	(p != 0 ? p + 1 : (s))
  #define	DIRONLY(s)	(p == 0 ? "./" : p == (s) ? "/" \
! 			 : strncpy(alloca((p - (s)) + 1), s, (p - (s))))
  
    /* $* is the stem from an implicit or static pattern rule.  */
    if (file->stem == 0)

Newsgroups: gnu.utils.bug
From: zoo@cygnus.com (david d `zoo' zuhn)
Subject: an end to -DUSG in grep sources
Organization: Cygnus Support -- +1 415 903 1434
Distribution: gnu
Date: Fri, 20 Nov 1992 01:51:49 GMT

Since USG is an obsolete #define to test for these days, here are patches
to grep 1.6 which remove all traces of USG from the source code.  You'll
need to re-generate the configure file from configure.in (with autoconf).

  david d 'zoo' zuhn |    There is great disorder under the heavens,
    cygnus support   |         and the situation is excellent.
    zoo@cygnus.com   |    

--- share and enjoy ---

Only in grep-1.6: Makefile
diff -ru2 grep-1.6/Makefile.in grep-zoo/Makefile.in
--- grep-1.6/Makefile.in	Sun May 17 10:35:19 1992
+++ grep-zoo/Makefile.in	Thu Nov 19 17:47:03 1992
@@ -32,5 +32,5 @@
 # -DSTDC_HEADERS	If you have ANSI C headers and libraries.
 # -DHAVE_UNISTD_H	If you have unistd.h.
-# -DUSG			If you have System V/ANSI C string
+# -DHAVE_STRING_H	If you have System V/ANSI C string
 #			and memory functions and headers.
 # -D__CHAR_UNSIGNED__	If type `char' is unsigned.
diff -ru2 grep-1.6/configure.in grep-zoo/configure.in
--- grep-1.6/configure.in	Mon May  4 13:30:54 1992
+++ grep-zoo/configure.in	Thu Nov 19 17:47:03 1992
@@ -4,5 +4,5 @@
 AC_PROG_INSTALL
 AC_STDC_HEADERS
-AC_USG
+AC_HAVE_HEADERS(string.h)
 AC_UNISTD_H
 AC_CHAR_UNSIGNED
diff -ru2 grep-1.6/dfa.c grep-zoo/dfa.c
--- grep-1.6/dfa.c	Tue May  5 19:32:11 1992
+++ grep-zoo/dfa.c	Thu Nov 19 17:47:04 1992
@@ -22,5 +22,5 @@
 #include <assert.h>
 
-#if defined(USG) || defined(STDC_HEADERS)
+#if HAVE_STRING_H==1 || defined(STDC_HEADERS)
 #include <string.h>
 #ifndef index
diff -ru2 grep-1.6/getopt.c grep-zoo/getopt.c
--- grep-1.6/getopt.c	Mon May  4 12:17:35 1992
+++ grep-zoo/getopt.c	Thu Nov 19 17:47:52 1992
@@ -24,5 +24,5 @@
 #define alloca __builtin_alloca
 #else /* not __GNUC__ */
-#if defined(sparc) && !defined(USG) && !defined(SVR4) && !defined(__svr4__)
+#if defined(sparc) && !defined(SVR4) && !defined(__svr4__)
 #include <alloca.h>
 #else
diff -ru2 grep-1.6/grep.c grep-zoo/grep.c
--- grep-1.6/grep.c	Tue May  5 19:40:20 1992
+++ grep-zoo/grep.c	Thu Nov 19 17:47:39 1992
@@ -21,5 +21,5 @@
 #include <stdio.h>
 
-#if defined(USG) || defined(STDC_HEADERS)
+#if HAVE_STRING_H==1 || defined(STDC_HEADERS)
 #include <string.h>
 #ifndef bcopy
diff -ru2 grep-1.6/regex.c grep-zoo/regex.c
--- grep-1.6/regex.c	Sun May 17 11:12:29 1992
+++ grep-zoo/regex.c	Thu Nov 19 17:48:10 1992
@@ -32,5 +32,5 @@
 #define alloca __builtin_alloca
 #else /* not __GNUC__ */
-#if defined(sparc) && !defined(USG) && !defined(SVR4) && !defined(__svr4__)
+#if defined(sparc) && !defined(SVR4) && !defined(__svr4__)
 #include <alloca.h>
 #else
@@ -56,5 +56,5 @@
 #else  /* not emacs */
 
-#if defined(USG) || defined(STDC_HEADERS)
+#if HAVE_STRING_H==1 || defined(STDC_HEADERS)
 #include <string.h>
 #ifndef bcopy

Newsgroups: gnu.utils.bug
From: dbl@visual.COM (David B. Lewis)
Subject: GNU Make 3.6.2 on MIPS Magnum RISC/os
Organization: Visual, Inc.
Distribution: gnu
Date: Fri, 20 Nov 1992 08:40:49 GMT

1) In Makefile, needs -lmld like for SGI
2) in job.c at tail end of init_siglist() last two cases should be commented
out as they are identical to earlier cases on this system.

Newsgroups: gnu.utils.bug
From: pinard@iro.umontreal.CA (Francois Pinard)
Subject: GNU shellutils: Question about which(1)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 14:11:17 GMT

   It is nice to have a seperate echo(1), but I still miss which(1).

In case it helps, the `type' builtin of many shells, among which
`bash', does something equivalent.

-- 
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: djm@eng.umd.edu (David J. MacKenzie)
Subject: gawk 2.14 const disagreement for fdopen on ultrix 4.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 13:54:38 GMT

Ultrix 4.2b on a Decstation using gcc 2.2.2.

I did `configure ultrix41' and had one small problem, shown below.

In general, it causes trouble to provide your own prototypes for
standard library functions, because various OS's disagree about the
consts.  If the system has STDC_HEADERS, let its headers provide the
prototypes; otherwise, just put in an old-style declaration.  Then you
won't conflict with anyone, and if you do your prerelease testing on a
system that provides prototypes, you'll still get type checking.

I've had similar problems with getopt and stdlib.h, and some string
functions, in the past.


gcc -DGAWK     -O2    -c io.c -o io.o
io.c:58: conflicting types for `fdopen'
/usr/local/gnu/lib/gcc-lib/decstation-ultrix4.2/2.2.2/include/stdio.h:181: previ
ous declaration of `fdopen'
make: *** [io.o] Error 1
djm@decoder:/afs/.glue.umd.edu/@sys/build/usr.local/gnu/gawk-2.14 28 $ grep fdo
pen io.c
extern FILE     *fdopen P((int, const char *));
extern FILE     *fdopen();
                                        rp->fp = fdopen(fd, mode);
        FILE *kludge = fdopen(fd, "r"); /* pclose needs FILE* w/ right fileno */
djm@decoder:/afs/.glue.umd.edu/@sys/build/usr.local/gnu/gawk-2.14 29 $ grep fdo
pen ~gnu/lib/gcc-lib/decstation-ultrix4.2/2.2.2/include/stdio.h
extern FILE *   fdopen( int __filedes, char *__type );
        *fdopen(),

Newsgroups: gnu.utils.bug
From: gb@mir.fb10.tu-berlin.de (Guenter Becker)
Subject: gawk-2.13  on sco v3.2.2
Organization: ZRZ/TU-Berlin
Distribution: gnu
Date: Mon, 16 Nov 1992 10:56:18 GMT

Good morning,

when installing gawk-2.13 on sco v3.2.2 with cc, a compiler error occurred  
in eval.c, which could be tracked down to a macro definition in gawk.h for  
'force_number', which apparently also causes msc5.1 under dos to bomb. A  
fix given in gawk.h using a variable called '_msc51bug' also works for  
sco.

To fix, either change gawk.h appropriately, or add -DDEBUG to the compiler  
options, which causes a much simpler form of this macro to be used, which  
works.

Let me add, that, after successful installation, gawk works fine, fast,  
and on lines of several kbytes length, which is beyond the capabilities of  
the awk included by sco.

G. Becker

Newsgroups: gnu.utils.bug