HDTenEightyP/NetNews huggingface dataset:
From: card@masi.ibp.fr (Remy CARD)
Subject: Bug in autoconf 1.1 ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 14:16:29 GMT

	Hi,

	I have found a bug in the configure script that comes with the
shellutils version 1.7.  This script seems to have been generated by autoconf
so I have looked at this program and patched it.

Description of the bug:
	On a Linux machine using gcc 2.2.2, the shellutils' configure
incorrectly assumes that tzname does not exist.  I have taken a look at
configure and it seems that it detects if tzname is present by trying to
compile a program containing 'extern char **tzname;'.  In Linux, tzname is
declared in time.h as 'extern char *tzname[2];' and gcc says that the two
declarations are not compatible.

	The fix is to change the declaration of tzname in acspecific.m4
contained in the autoconf distribution.  The patch is enclosed at the end of
this mail.

--
Remy Card
card@masi.ibp.fr

*** acspecific.m4.old	Mon Sep  7 15:07:08 1992
--- acspecific.m4	Mon Sep  7 15:07:21 1992
***************
*** 484,490 ****
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
  #ifndef tzname /* For SGI.  */
! extern char **tzname;
  #endif], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
--- 484,490 ----
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
  #ifndef tzname /* For SGI.  */
! extern char *tzname[];
  #endif], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
From: warmerda@pci.on.CA (Frank Warmerdam)
Newsgroups: gnu.utils.bug
Subject: tar-1.11
Date: 15 Sep 92 04:53:00 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Gentlemen,

I have succesfully built GNU tar 1.11 under IRIX 4.0.1, and run into
a problem with the simple command "tar cvf src.tar rmt.c".  From dbx
I see the following:

(dbx) where
>  0 quote_copy_string(string = (nil)) ["/usr/r_d/warmerdam/tar-1.11/port.c":784, 0x410094]
   1 print_header() ["/usr/r_d/warmerdam/tar-1.11/list.c":536, 0x40d304]
   2 finish_header(header = 0x10018008) ["/usr/r_d/warmerdam/tar-1.11/create.c":1276, 0x404bcc]
   3 dump_file(p = 0x7fffc7f0 = "tar.c", curdev = -1, toplevel = 1) ["/usr/r_d/warmerdam/tar-1.11/create.c":488, 0x403434]

(the stack seems to have been corrupted since the trace does not go
 all the way back up to main())

The problem seems to be producing verbose output while _creating_ an
archive.  The global current_file_name is NULL.  I tried tracing the
use of current_file_name to find out why, but became rather frustrated.
The only place I can that the pointer current_file_name is actually
set is in list.c, function read_header() which does not seem to be
invoked when creating an archive.

If you have any trouble reproducing this error please feel free to ask
for more details.  I will get the code and executables handy for 
a few days.  

Later,

-------------------------------------------------------------------------------
Frank Warmerdam | Who can give them back their lives | warmerda@pci.on.ca    
Software Artist | and all those wasted years? - Rush | 
Newsgroups: gnu.utils.bug
From: cgf@ednor.UUCP (Chris Faylor)
Subject: Problems with 12u7 patches to common.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 13:51:38 GMT

Patch complains about one of the diff records being too long in your recent
posting to comp.sources.bugs.

This is the offending record:

***************
*** 157,168 ****
  EXT char *revision INIT(Nullch);	/* prerequisite revision, if any */
  
  char *malloc();
  char *realloc();
  char *strcpy();
  char *strcat();
! long atol();
  long lseek();
  char *mktemp();
! #if 0
  #ifde();			<<--- Screwed up around here?
  char *strcat();
! long atol();
  long lseek();
  char *mktemp();
! #if 0
  #ifdef CHARSPRINTF
  char *sprintf();
--- 166,185 ----
  EXT char *revision INIT(Nullch);	/* prerequisite revision, if any */
  
+ #include <errno.h>
+ #ifndef errno
+ extern int errno;
+ #endif
+ 
+ FILE *popen();
  char *malloc();
  char *realloc();
+ long atol();
+ char *getenv();
  char *strcpy();
  char *strcat();
! char *rindex();
  long lseek();
  char *mktemp();
! #if 0				/* This can cause a prototype conflict.  */
  #ifdef CHARSPRINTF
  char *sprintf();
***************
*** 171,175 ****
  #endif
  #endif
- char *getenv();
  
  #if !defined(S_ISDIR) && defined(S_IFDIR)
--- 188,191 ----

Was this just garbled in transmission to our site or was there a problem
in the posting?

Regards,
Chris Faylor
cgf@bbc.com

Newsgroups: gnu.utils.bug
From: epperly@osnome.che.wisc.edu (Tom Epperly)
Subject: Fontutils-0.5 linking problem with gcc v2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 6 Sep 1992 07:59:56 GMT

This bug report is for version 0.5 of the font utilities.  I am using
a DECstation 3100 running Ultrix 4.2, and I am using gcc version 2.2.2
as my compiler.

I have altered the GNUmakefile that configure produced to use CC="gcc -O"
instead of CC=cc.  When I make the utilities, the linking step fails
reporting that "__new_handler" has both a large and small symbol(see
output below).

I got rid of the error by adding -DNO_LIBGXX_MALLOC to CFLAGS in
GNUmakefile, rm lib/malloc.o, and then remaking.  I haven't had a
chance to test this proposed fix.

# error free lines deleted
gcc -O -o bpltobzr -L/home/X11R5/lib -g  bpl.o main.o version.o .././lib/lib.a .././bzr/bzr.a .././lib/lib.a  -lm 
__new_handler: both a large and small symbol (possible gp relocation errors may result)
ld:
.././lib/lib.a(malloc.o): gp relocation out-of-range in .text section for relocation entry 9 for symbol: __new_handler
.././lib/lib.a(malloc.o): above gp relocation entry for non .sdata or .sbss symbol
All data will fit into the global pointer area
Best -G num value to compile all -count'ed objects
creating bpltobzr with is 1920 (or greater)
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).
gp relocation out-of-range for small data or bss by,
              0 in the positive direction,
           3888 in the negative direction.
collect: /usr/bin/ld returned 1 exit status
make[1]: *** [bpltobzr] Error 1
make[1]: Target `default' not remade because of errors.
# error free lines deleted
gcc -O -o bzrto -L/home/X11R5/lib -g  ccc.o char.o input-ccc.o main.o metafont.o oblique.o pstype1.o pstype3.o psutil.o text.o version.o .././lib/lib.a .././gf/gf.a .././pk/pk.a .././bzr/bzr.a .././tfm/tfm.a .././lib/lib.a  -lm 
__new_handler: both a large and small symbol (possible gp relocation errors may result)
ld:
.././lib/lib.a(malloc.o): gp relocation out-of-range in .text section for relocation entry 9 for symbol: __new_handler
.././lib/lib.a(malloc.o): above gp relocation entry for non .sdata or .sbss symbol
All data will fit into the global pointer area
Best -G num value to compile all -count'ed objects
creating bzrto with is 18432 (or greater)
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).
gp relocation out-of-range for small data or bss by,
              0 in the positive direction,
          12224 in the negative direction.
collect: /usr/bin/ld returned 1 exit status
make[1]: *** [bzrto] Error 1

This same type of error is repeated for charspace, fontconvert,
bbcount, imageto, imgrotate, limn, and xbfe.

Newsgroups: gnu.utils.bug
From: ilan343@violet.berkeley.edu (Geraldo Veiga)
Subject: Indent 1.6 bug (-di option) (was: indent 1.6 and typedef)
Organization: University of California, Berkeley
Distribution: gnu
Date: Sat, 5 Sep 1992 05:08:41 GMT

In article <9209031707.AA11529@chopin.epic> hxl@chopin.UUCP (Charlie Xiaoli Huang) writes:
>Hi,
>
>I installed indent 1.6 on a Sun IPC runnning 4.1.1 and 
>
>	original:
>
>	typedef struct foo {
>		int bar;
>	} foo_t;
>
>The outcome will always become
>
>	typedef struct foo {
>		int bar;
>	}
>	foo_t;
>
I have the same problem as above with any "struct" declaration.  The
patch posted in a ealier message fixes that.  I have an additional
problem when usin "indent -npro -di10" in the following code:


struct
  {
     int       i;
     float     b;
  } a[10];

The result is:

struct
  {
    int       i;
    float     b;
  }

a         [10];


I don't remember having these problems with previous version of indent
( < 1.6 ).



Newsgroups: gnu.utils.bug
From: joost@cadlab.CAdlab.DE (Michael Joosten)
Subject: GNU make-3.62, SVR4 and long filenames
Reply-To: joost@cadlab.cadlab.de
Organization: CADLAB, Paderborn, FRG
Distribution: gnu
Date: Wed, 9 Sep 1992 20:04:20 GMT

Hi,

after the struggle to get our socket based C++ RPC library on a System V
Release 4 box (SINIX 5.41 - don't ask, be happy about your ignorance...) I
discovered a funny thing: GNU make insisted on re-making some files again and
again. Eventually I discovered that SVR4 has a special extension for archives,
allowing them to store filename longer than 15 chars. This is made by a
special entry '/' (that is "//<8spaces here>") that contains a "filename
table". The code in arscan.c doesn't know about that and is thus failing for
archive files with longer names. 

Is anybody aware about that, especially some GNU make maintainer?? If so, will
it be fixed by the use of the BFD library in (some) next release? If not, does
it make sense if I dig a bit into arscan.c to enhance it for SVR4??

Michael
--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Newsgroups: gnu.utils.bug
From: nelson@reed.edu (Nelson Minar)
Subject: GNU finger 1.35 - small installation quibbles, misfeatures
Organization: Reed College, Portland, OR
Distribution: gnu
Date: Mon, 7 Sep 1992 00:03:03 GMT

I've installed GNU finger 1.35 on a bunch of Ultrix 4.2 machines here,
and it basically seems to run OK. I haven't tried to make it mesh with
the rest of the network (NeXTs, Suns, Sequents) yet - I hope that
works.

There is a bug on line 79 of lib/site/birthdate.c. The call to bcopy
is malformed - one of the arguments is not a pointer, and that
prevented birthdate.c from compiling.

I also wonder if GNU finger could handle basic name-requests better.
Under Ultrix, the default finger behaviour when given a name is to
always tell you all people whose real name or username matches that
string. Ie: finger "nelson@romulus.reed.edu" will (would, if I weren't
running GNU finger) tell you about me (nelson@reed.edu, Nelson Minar),
but it will also tell you about "Frank Nelson Womack" and the user
"anelson", etc etc. This is a liberal approach.
 
GNU finger is more conservative. "finger nelson" seems to only tell if
you if the user with the name nelson is on at that moment. If nelson
is never logged in, it complains that there is no user nelson. If you
try "finger --info nelson", it will then tell you about the user
nelson, but still doesn't tell you about all the other people with
"Nelson" in their names. "finger --info ' Nelson'" seems to finally
get you most of the people.

Unfortunately, GNU finger's unwillingness to give out information
makes it harder for people to get e-mail addresses. I've modified
in.fingerd so that instead of sending out a canned error message it
spits out the contents of the file. I've also changed the error
message to something a little more helpful, suggesting that users try
-l if they are trying to find people's e-mail addresses. (the current
message mentions something about -l and "mail aliases", but that's a
little cryptic).

Basically, GNU finger 1.35 is pretty nice. Thanks for doing the
cleanup work to make it into a more usable program.

(anyone got faces online? We've got 1 so far. Oh, there's a bug in the
X display function whereby faces come up in inverse. And another bug -
the window isn't big enough to display the save/print buttons.)
-- 
                __
nelson@reed.edu \/       Before the cream sits out too long, you must whip it

Newsgroups: gnu.utils.bug
From: cjm@trillian.mincom.oz.AU (Chris Moran)
Subject: Bugs in GNU tar 1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 21:00:36 GMT

    Hi there. I have had some problems building GNU tar 1.11 on an SGI Iris,
running IRIX 4.0.4:

1.  The public routine valloc() is defined in both port.c and malloc.c. This
    causes a link error. My workaround is to compile with "-DHAVE_VALLOC",
    which causes port.c to ignore its definition of valloc().

2.  If getdate.y is parsed with bison, the generated C code contains
    references to alloca(). Now under IRIX, alloca() is a std C library
    routine, and it requires alloca.h to be brought in for correct compilation.
    alloca.h is not brought in, for two reasons:

    1.  The #include <alloca.h> at the top of getdate.y does not test for
        the manifest define HAVE_ALLOCA_H. (And looking in getopt.c, getdate.y
        seems to be missing a lot of other tests as well).

    2.  There are no rules in the Makefile for building a .o from a .y.
        make therefore uses its internal rules, which will not reference the
        make variable "DEFS", where all the manifest defines are setup. So
        y.tab.c never knows about HAVE_ALLOCA_H.

3.  There is a commented out line in the Makefile, just above the target
    "all", for the definition of "AUX", which seems to cause problems with
    make under IRIX - make will not recognize the "all". Deleting the
    commented out line solves the problem.

4.  In the Makefile, for the target "install", it tries to install tar.info,
    which is not supplied with the pkg.

5.  I compiled GNU tar on the Iris in K&R mode (cc -cckr). The IRIX
    pre-processor when invoked in this mode complains about any whitespace
    present on a line prior to a pre-processor statement (e.g. " #ifdef").
    I edited the files buffer.c, create.c, extract.c, getopt.c, port.h and
    regex.c to remove such whitespace.


Eventually, I was able to build tar, but now it core dumps :-). I'll let you
know if I find anything.

Thanks for your time.


Chris Moran
chris.moran@mincom.oz.au


Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: Re GDB, BFD and COFF files for 68k
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 22:28:04 GMT

Well, after a bit of research, I realised that it is a bad idea to take 
advantage of some of the nice features of GLD and BFD.

If you use GLD (1.94 or 2.0) to translate from a.out into COFF file formats 
then you lose nearly all of the symbolic debugging info. Only addresses 
are preserved and GDB is lost without more information.

So, it is currently impossible to produce COFF-68k executables with debug info
in them since gas-1.92.3 does not correctly produce COFF output (at least it didn't
last time I tried it - maybe I should try it with a newer version of BFD lib) 
for 68k.

It would be good if someone could look into the following:

1.  To be able to transliterate a.out debugging info into COFF debugging info
	using BFD (or some other backdoor method inside GLD).

2. To fix GAS to produce 68k COFF output properly. 

I don't know of any 68k ICE/Emulators which accept a.out format, with the
possible exception of VxWorks tools and COFF is very useful to have around.


Andrew Smith
SynOptics Communcations Inc.





Newsgroups: gnu.utils.bug
From: jla@gnu.ai.mit.edu (Joseph Arceneaux)
Subject: indent-1.6 -troff : character constants
Reply-To: jla@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 11:25:01 GMT

   From: gnu@pdv2.fmr.maschinenbau.th-darmstadt.de (GNU - Mutter aller PDVSoftNummern)
   Date: Mon, 14 Sep 1992 01:06:43 GMT

   GNU-indent-1.6 does not handle character constants in a correct manner
   using "-troff" option. It generates wrong constants, or keeps sequence
   of characters with special meaning to "troff", which will generate
   everything else than desired.

GNU indent doesn't really support -troff.  Ideally, indent should be
rewritten and provide support for TeX output.  If someone would like
to undertake this project, please send me email.

Joe

----
Joseph Arceneaux
Free Software Foundation
jla@ai.mit.edu                PO Box 460633
+1 415 285 9088               San Francisco, CA 94146

Help abolish software patents -- send mail for details.


Newsgroups: gnu.utils.bug
From: jbotz@orixa.mtholyoke.edu (Jurgen Botz)
Subject: tar-1.11 fails on DEC MIPS Ult-4.2
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 01:30:41 GMT

The default configure for tar produces a broken executable on a
DECstation under Ultrix 4.2.  (I have gcc-2.2.2 and configure finds
and uses it.)

I haven't had time to look more closely at what might be causing it,
but although it reads and writes tapes correctly, upon unarchiving it
fails when it tries to set the modes of the files it creates.  Looks
like some routine gets garbage for a filename...

   tar: cannot change mode of file <assorted 8bit characters here> to
   33152 : no such file or directory

I'm currently swamped with work, otherwise I'd have sent a fix.
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629

Newsgroups: gnu.utils.bug
From: halvers@sol.CRd.ge.COM (peter c halverson)
Subject: inconsistent semantics for imageto -baseline arg???
Reply-To: Pete Halverson <halverson@crd.ge.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 19:27:55 GMT

The documentation for imageto, including the example given, indicates that
the values given as -baseline arguments are scanlines numbered relative to
the topmost (first) scanline of the corresponding image row, e.g. given an
image,

       01234567890123456789
      0
      1         x
      2 x   x   x
      3         x
      4 x   x   x   xxxxx
      5 x   x   x   x x x
      6     x       x x x
      7   xx
      8
      9
     10 xxxxxxxxxxxxxxx

the default baselines should be "4,0".  When I analyzed an image and
provided the appropriate baseline specs, however, the resulting imageto
output font was not correct; glyph baselines were off by a significant
percentage of the total height (although consistently so within characters
from a particular image row).

Further experimentation and analysis of the print-guidelines output makes
it appear is if imageto is setting default baselines relative to the
*bottommost* (last) scanline of an image row; e.g. the baselines for the
above example need to be "1,0".  Furthermore, correcting the original
baselines based on this hypothesis yielded a correct font!

Dunno if this is a documentation bug or an imageto problem, but something's
clearly not right.  The actual speciman image and IFI file involved are
available if you'd like to see them.

pch


Newsgroups: gnu.utils.bug
From: sanders@server.physics.lsa.umich.edu (Michael Sanders)
Subject: Re: MS-DOS Version of diff Exhausts Memory
Organization: Physics Department, University of Michigan
Distribution: gnu
Date: Thu, 10 Sep 1992 21:03:16 GMT

In article <87kn3yb.westes@netcom.com> westes@netcom.com (Will Estes) writes:
>From: westes@netcom.com (Will Estes)
>Subject: MS-DOS Version of diff Exhausts Memory
>Date: 3 Sep 92 00:07:36 GMT

>Using the MS-DOS version of diff 1.15, I occasionally get an error
>message reporting that memory has been exhausted (this on a machine that
>has 15 megs of extended memory).  Do other users of the
>MS-DOS version get the same error?  Can someone point me to an ftp site
>for a version of diff that has been made to work with VCPI, DPMI, or EMS
>under MS-DOS?

The djgpp directory on the simtel mirrors:
Directory PD1:<MSDOS.DJGPP>
 Filename   Type Length   Date    Description
==============================================
DJDEV108.ZIP  B  778559  920820  Minimum development environment (djgpp)
contains (among much other stuff) a version of diff.
It's also available from its original source:
barnacle.erc.clarkson.edu
in directory:
ftp/pub/msdos/djgpp

Michael Sanders                                Internet: t.m.sanders@umich.edu
Physics Department                             Bitnet: sanders@umiphys
University of Michigan                         Telephone: (313)936-0799
Ann Arbor, MI 48109-1120                       FAX: (313)763-9694

Newsgroups: gnu.utils.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: GNU tar 1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 20:04:25 GMT

Installing GNU tar version 1.11 on a Next running OS release 2.1 revealed the
following:


1.  Files buffer.c and diffarch.c declare valloc() as

	extern char *valloc();

which conflicts with the Next's definition in /usr/include/stdlib.h:

	extern void *valloc(size_t size);


2.  The configure script fails to add -DBSD42 to the list of compilation
definitions.  It checks for the presence of /vmunix, but the Next boots from
/sdmach.

3.  When the final executable is linked, malloc.o is linked in, which causes
name conflicts with malloc, free, ...  in the Next shared libraries.  The
configure shell script test for /vmunix to see whether to use tar's malloc.

Newsgroups: gnu.utils.bug
From: meyering@cs.utexas.edu (Jim Meyering)
Subject: indent-1.6 left-justifies `#' of  preprocessor directives
Organization: U of TX at Austin CS Dept
Distribution: gnu
Date: Sat, 12 Sep 1992 05:18:55 GMT

Hi,

I just noticed that indent-1.6 left-justifies the `#' of preprocessor
directives.  Most of the time this is what one wants, but for portability
of #pragma directives with pre-ansi compilers it is inappropriate.

For example, in most of the GNU utilities that use alloca, there is
some code that looks like this:

#ifdef _AIX
 #pragma alloca
#else /* not _AIX */
...
#endif

in which the #pragma is deliberately indented to hide it from pre-ANSI
compilers.

Running indent-1.6 (even with --leave-preprocessor-space)
removes the space preceding #pragma.

Jim Meyering             | Member of the League for Programming Freedom
meyering@cs.utexas.edu   | Contact me or league@prep.ai.mit.edu for more info.

Newsgroups: gnu.utils.bug