HDTenEightyP/NetNews huggingface dataset:
From: tom@smart.bo.open.DE (Thomas Neumann)
Subject: oleo CPU usage
Organization: News at smart
Distribution: gnu
Date: Mon, 4 Jan 1993 15:15:16 GMT

I've just compiled oleo-1.2.1 on a NeXT running NeXTSTEP 3.0. Things that
seem noteworthy:

	- oleo uses CPU time like crazy even when no user interaction
          takes place. Looks like it is waiting for keyboard input in raw
	  mode a little bit too busy (just a guess).

	- the header file dependencies in Makefile.in look like some
	  `make depend' generated stuff. It's not a good idea to have
	  this in Makefile.in, which should be as generic as possible.
	  I noticed this because Makefile.in contains a direct dependency to
	  /usr/include/ctype.h which NeXTSTEP 3.0 does not have (it's
	  in /NextDeveloper/Headers/ansi/ctype.h).
	  This is of course trivial to fix, but nevertheless annoying.

	- when a floating point value is entered into a cell it gets
	  reformatted to use the maximum number of possible decimal
	  digits, e.g. one enters 42.1 and the cell gets filled with
	  something like 42.10000000001.
	  I know that this is due to a bug (or non-POSIX conformance)
	  in NeXTs sprintf formatting code and therefore not strictly
	  a bug in oleo, however, I suspect there may be more platforms
	  that have this problem so maybe oleo should do it's own formatting,
	  at least when it comes to screen output.


bye -- Thomas

Newsgroups: gnu.utils.bug
From: phil@compnews.co.UK (Phil Male)
Subject: Re: gdbm 1.5 loses key chain
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 14:00:48 GMT

Did you apply the patch I pushed out about a year ago to gdbm 1.5? There is a
bug in the cache management routines in the reorganise code. We have been
running gdbm 1.5 on several very large databases for over a year now with no
problems.

I mailed the patch to the author and on this list, but short of that I don't
know where else to push it to!  If anyone does want it then send me some
mail.

-- 

phil 
   ___/   /
   /_/)  /       Phil Male, Director, Information Systems Engineering
  / /_ '/  Computer Newspaper Services, The Bishops Manor, Howden, DN14 7BL
 / / ///

New York's got the ways and means;
Just won't let you be.
		-- The Grateful Dead

Newsgroups: gnu.utils.bug
From: jv@mh.NL (Johan Vromans)
Subject: Re: oleo-1.2.1
Organization: Multihouse Automation, the Netherlands
Distribution: gnu
Date: Mon, 11 Jan 1993 10:07:56 GMT

In article <199301071659.AA27767@garf.fe.up.pt> jperes@garfield.fe.up.pt (Maria Joana Peres) writes:

> Hello! I'm with a problem with oleo-1.2.1 : I compile it then when I
> execute the command oleo it doesn't do nothing. I expected that it
> would open a window but no. 
> 
> I have some warnings at the compilation and I'm sending you them:

> gcc -c -g  -DHAVE_SYS_TIME_H=1 -DHAVE_X11_X_H=1 -DHAVE_SETITIMER=1 -DHAVE_RINT=1 -DHAVE_RENAME=1 -DHAVE_VPRINTF=1 -DHAVE_INDEX=1 -DHAVE_GETCAP=1 -DHAVE_STRSTR=1 -DHAVE_BCOPY=1 -DHAVE_BCMP=1 -DHAVE_BZERO=1  -I. parse.tab.c
> In file included from utils.h:21, from global.h:23, from parse.y:51:
> /usr/include/stdio.h:140: warning: `NULL' redefined
> /usr/local/lib/gcc-lib/vax/2.2.2/include/stddef.h:137: warning: this is the location of the previous definition

Aha! You're running on a VAX. On this system, Oleo gets stuck in a
sequence of FPE traps during setup. I'm not aware of a solution or
work-around. 

	Johan
--
Johan Vromans				       jv@mh.nl via internet backbones
Multihouse Automatisering bv		       uucp:..!{uunet,sun4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands  phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------

Newsgroups: gnu.utils.bug
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Subject: printing hardcopy of m4 texinfo documentation
Reply-To: friedman@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 06:47:50 GMT

>In order to print out a hardcopy of the texinfo file I run 
>
>	% tex m4.texinfo
>
>The response is then:
>
>	% This is TeX, C Version 3.14
>(m4.texinfo
>! I can't find file `texinfo'.
>l.1 \input texinfo^^I
>...

I don't remember if version one came with texinfo.tex included.  Version
1.0.3, which is currently available on any GNU mirroring site or on
prep.ai.mit.edu, has a copy. 

Newsgroups: gnu.utils.bug
From: phil@cs.wwu.edu (Phil Nelson)
Subject: gdbm: alloca on SCO
Reply-To: phil@cs.wwu.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 21:42:37 GMT

Have you gotten gdbm-1.5 working on your SCO?  Are you using gcc?

--Phil

Newsgroups: gnu.utils.bug
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Subject: Question about texinfo distribution
Organization: Universite de Montreal
Distribution: gnu
Date: Thu, 7 Jan 1993 17:12:44 GMT

At prep.ai.mit.edu:/pub/gnu one can find the file texinfo-2.16.README which is
identical to the file README in the directory texinfo-2.16 that we can get from
the same place.

Is there a special reason why the information is duplicated?

-- 
Pierre Gaumond.        gaumondp@ERE.UMontreal.CA
Services Informatiques, Universite de Montreal. 
C.P. 6128, Succursale "A", Montreal,            
Quebec, Canada.   H3C 3J7                       

Newsgroups: gnu.utils.bug
From: terra@diku.dk (Morten Welinder)
Subject: Gnu regex-0.11 -- minor mistake in the tests
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 14:00:22 GMT

Scrolling through the test material in the regex-package (version 0.11)
I found the following two lines:

----------- ./test/psx-extend.c --- 42094 Sep 13 14:58 -------------
  TEST_SEARCH ("a|b", "cb", 0, 2);
  TEST_SEARCH ("a|b", "cb", 0, 2);
--------------------------------------------------------------------

It is line 127 and 128. One of the "cb"s should be a "ca", I think.
Doing the same test twice makes no sense.

Sincerely,

Morten Welinder
terra@diku.dk

Newsgroups: gnu.utils.bug
From: bothner@cygnus.com
Subject: Re: suggestions for getopt*.c in libiberty
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 16:07:18 GMT

> I want to put it after -lc, since any existing routines on a particular
> Unix are probably more efficient than the versions in -liberty.

Most routines in libiberty are there only if there is no
corresponding routine in libc.  Any other routines are unlikely
to be any more efficient in libc.

The efficiency of getopt is particularly irrelevant - even if
it made a difference, why do you think the system version is preferable?

> Also, it would be nice if libiberty.tar.Z, with it's own configure, could
> appear in prep.ai.mit.edu:~ftp/pub/gnu.

There are no plans for this, since libiberty is just a utility library
for Cygnus releases.  It has no particular deocumentation or specification.
If non-Cygnus packages start using it, we might re-consider.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.utils.bug
From: cudcv@csv.warwick.ac.uk (Rob McMahon)
Subject: nm version 2.0 - behaviour of -o on multiple libraries
Organization: Computing Services, University of Warwick, UK
Distribution: gnu
Date: Fri, 8 Jan 1993 12:15:07 GMT

binutils-2.0, SunOS 4.1.3, SPARCserver 690.

For `nm -o libX*.a', GNU nm produces output like

------------------------------------------------------------------------------
libX11.a:

Context.o:
Context.o:00000000 t _ResizeTable
Context.o:000002e4 T _XDeleteContext
Context.o:00000260 T _XFindContext
Context.o:00000138 T _XSaveContext
Context.o:000000cc t __XFreeContextDB
Context.o:         U _calloc
Context.o:         U _free
Context.o:         U _malloc
Context.o:00000000 t gcc2_compiled.

Depths.o:
Depths.o:00000000 T _XListDepths
...
------------------------------------------------------------------------------

whereas Sun's nm gives

------------------------------------------------------------------------------
libX11.a:
libX11.a:Context.o:00000000 t _ResizeTable
libX11.a:Context.o:000002e4 T _XDeleteContext
libX11.a:Context.o:00000260 T _XFindContext
libX11.a:Context.o:00000138 T _XSaveContext
libX11.a:Context.o:000000cc t __XFreeContextDB
libX11.a:Context.o:         U _calloc
libX11.a:Context.o:         U _free
libX11.a:Context.o:         U _malloc
libX11.a:Context.o:00000000 t gcc2_compiled.
libX11.a:Depths.o:00000000 T _XListDepths
...
------------------------------------------------------------------------------

I find the latter behaviour far superior.  My normal use of -o is for grepping
for a symbol, and if the output doesn't contain the filename, I'm no better
off.

Cheers,

Rob
-- 
UUCP:   ...!mcsun!uknet!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

Newsgroups: gnu.utils.bug
From: karl@owl.HQ.ILeaf.COM
Subject: gptx 0.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 20:32:25 GMT

gptx 0.2 doesn't compile on a sun 4 running 4.1.2 because the functions
mcheck and strerror are undefined.  Both have replacements supplied, but
configure doesn't check for them.

Newsgroups: gnu.utils.bug
From: hahn@sunshine.labs.tek.COM (Doug Hahn)
Subject: bug report, gas 1.38, hack solution
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 00:59:02 GMT

Using gas 1.38, I cross assembled this file on sparc2 sunos 4.1 to 68k
target: 

        .globl  lcd_init, lcd_pwrup
		.text
		.even
lcd_init:
		movel	#	0x00f00000		,a1
msg_pu:
		.ascii	"POWER-UP DIAGNOSTICS"
		.byte	0
		.even
lcd_pwrup:
		movel	#	0x00f00000		,a1
		lea		pc@(msg_pu),a2
		moveb   #		0x42 ,a1@(     1 )
		moveb	a2@+,d0
		.ascii	"garbagegarbagegarbagegarbagegarbagegarbagegarbagegarbage"
		.byte	0

and in the resulting object code, the lea offset is off by 2. (actual
offset is msg_pu - 2) ie. (ala gdb)
0x22 <lcd_init+34>:     lea 0x4 <lcd_init+4>,a2
or for the more exacting:
0x22 <lcd_init+34>:     0x45faffe4

I tried some other insns using pc relative addressing (well, at least
movel) and that didn't  seem to work either.

I did this:

sunshine /gas-1.38/ diff -c2 ../../Fall92/gas-1.38/write.c write.c
*** ../../Fall92/gas-1.38/write.c       Thu Oct 11 09:26:15 1990
--- write.c     Wed Jan  6 16:10:59 1993
***************
*** 1089,1094 ****
              add_number += add_symbolP -> sy_value;
              add_number -=
! #ifndef NS32K
                      size +
  #endif
                      where + fragP -> fr_address;
--- 1089,1096 ----
              add_number += add_symbolP -> sy_value;
              add_number -=
! #if !defined(NS32K)
! #if 0
                      size +
+ #endif
  #endif

because according to the 68k manual, pc relative is calculated from
the beginning of the operand, not the end.  It worked fine.  Does not
seem to affect compiler generated assembly because pc relative does not
seem to be used (except for jump tables where this an absolute
expression is used as an operand).

So what machine DOES have to add in size?

  -- Doug

Newsgroups: gnu.utils.bug
From: barbour@eagle.fsl.noaa.gov (James W. Barbour)
Subject: Looking for a new tar manual
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 23:21:55 GMT

Hello,

It had been a while since I read the NEWS in tar 1.11.1 and I thought I
would check and see how the new tar manual was progressing.

In particular, I'm trying to figure out about incremental dumps and the
--volno-file switch.

Any help, pointers, etc would be appreciated.

Thanks,

Jim Barbour  --   barbour@fsl.noaa.gov

Newsgroups: gnu.utils.bug
From: pdp@stat.ufl.edu (Phil Padgett)
Subject: Problem with finger 1.36
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 01:34:27 GMT

We just got and compiled version  1.36 of the finger program.  We are
running a mixed network consisting of Sun IPX's, ELC's, etc running Sun
OS 4.1.3 and DECstations running Ultrix 4.3.  The Sun binary was
compiled with the gcc compiler.  The Dec binary was compiled with both
the DEC mips cc and the gcc compiler.  Both Dec compilers have the same
problem.  Configure was run on both platforms.  It correctly determined
that the Sun's were big endian and the Dec's were little endian.
However then finger is typed, the idle time on the Dec's is wrong.  It
appears in years.  Note the following output:
User     Real Name         What    Idle  TTY  Host      Console Location
littell  Ramon Littel               57 yea *p0 mako     (:0.0)
pdp      Phil Padgett                      *p1 marlin   (bstat)
statman  Chuck Kincaid               4:47  *p0 mullet   (128.227.8.68)
yang     Mark Yang                   1:51  *p6 marlin   (bluegill)

The following is the clients file:
amberjack
bamboo
banana
barracuda

etc.

marlin
wirrah
yaupon
yellowfin
The mailhost file contains the following:

stat.ufl.edu  (this is marlin)

The serverhost file contains the follwing:

stat.ufl.edu  (marlin again)

Note that marlin is a 4 processor Sun server also running Sun OS 4.1.3.
It contains the mail spool which is amd mounted to the clients (mail
is forwarded there for processing).  Everyone's account contains a 
.forward file with username@stat.ufl.edu.

Any suggestion on the problem with incorrect idle time would be
appreciated. 

Phil Padgett
pdp@stat.ufl.edu

Newsgroups: gnu.utils.bug
From: cgehman@lion.mlb.semi.harris.com (Corey Gehman)
Subject: BUG REPORT on GNU tar 1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 06:58:58 GMT

The ownership on directories is not change to the original owner (files do
get set correctly).  Both attempts as root with and without --same-owner.

This is with GNU tar 1.11.1 (from prep.ai.mit.edu) on SunOS 4.1.2 running on
a sun4c architecture (haven't tried any others)

-Corey
cgehman@sunman.mlb.semi.harris.com

Newsgroups: gnu.utils.bug
From: jbotz@orixa.mtholyoke.edu (Jurgen Botz)
Subject: tar-1.11.1: directory owner/modes don't get restored
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 05:08:23 GMT

I'm using tar-1.11.1 on a DECstation under Ultrix 4.2 and I'm finding
that directory ownerships/modes don't get restored (i.e. when running
as root and with -p).  Instead directories are created with owner root
and mode 700.  Files are restored properly.

Anybody have a fix for this?  Please?

Are we going to see a bug-fix release for tar any time soon?  A tar
1.11.2 would be nice... I know quite a few serious bugs have been
reported since 1.11.1 was released in September.

--
Jurgen Botz, jbotz@mtholyoke.edu
Northampton, MA, USA

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: [rouilj@ra.cs.umb.edu: Re: gnu mt and dd]
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 05:50:44 GMT

GNU dd and GNU mt on a Sun 4/490 running 4.1.2 have trouble talking to
an Exabyte drive.  (At least I'm pretty sure /dev/nrst12 is an Exabyte.)

I realize that without the actual tape in question, you probably
can't do anything about this, but on the offchance that this will be
useful, I'm passing it along.

From: "John P. Rouillard" <rouilj@ra.cs.umb.edu>
To: karl@ra.cs.umb.edu (Karl Berry)

	gnu dd   if=/dev/nrst12

(console screen reported DMA on odd byte alignment)

gnu dd returned immediately with no data. This was after it had
produced data from the first file correctly.

	gnu mt -f /dev/rst12 status

returned bogus info about the location on the tape when compared with
/bin/mt.

-- John

Newsgroups: gnu.utils.bug
From: jjc@jclark.com (James Clark)
Subject: time 1.4 incorrectly declares execvp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 22:55:33 GMT

In time 1.4, time.c declares execvp() incorrectly. POSIX says the type
of the second argument is `char *const *' not `const char **'.

*** time.c~	Mon Jan 11 22:45:35 1993
--- time.c	Mon Jan 11 22:51:08 1993
***************
*** 81,87 ****
  #endif
  
  #ifndef _POSIX_VERSION
! int execvp P_((const char *, const char **));
  int fork P_((void));
  void _exit P_((int));
  #endif /* !_POSIX_VERSION */
--- 81,87 ----
  #endif
  
  #ifndef _POSIX_VERSION
! int execvp P_((const char *, char *const *));
  int fork P_((void));
  void _exit P_((int));
  #endif /* !_POSIX_VERSION */
***************
*** 637,643 ****
      error (1, errno, "cannot fork");
    else if (pid == 0)
      {				/* If child. */
!       execvp (cmd[0], (const char **) cmd);
        error (0, errno, "cannot run %s", cmd[0]);
        _exit (errno == ENOENT ? 127 : 126);
      }
--- 637,643 ----
      error (1, errno, "cannot fork");
    else if (pid == 0)
      {				/* If child. */
!       execvp (cmd[0], (char *const *) cmd);
        error (0, errno, "cannot run %s", cmd[0]);
        _exit (errno == ENOENT ? 127 : 126);
      }

Newsgroups: gnu.utils.bug
From: gaumondp@ere.umontreal.CA (Gaumond Pierre)
Subject: m4 1.0.3 installation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 20:32:57 GMT

With m4 version 1.0.3, it is not possible to install m4 where we want. Here
is the patch to fix it.

% diff -u Makefile.in-dist Makefile.in
--- Makefile.in-dist	Mon Jan 11 15:05:58 1993
+++ Makefile.in	Mon Jan 11 15:06:42 1993
@@ -39,7 +39,7 @@
 LIBS = @LIBS@
 LIBOBJS = @LIBOBJS@
 
-prefix = /usr/local
+prefix = @prefix@
 binprefix = 
 exec_prefix = $(prefix)
 bindir = $(exec_prefix)/bin

--
Pierre Gaumond.        gaumondp@ERE.UMontreal.CA
Services Informatiques, Universite de Montreal. 
C.P. 6128, Succursale "A", Montreal,            
Quebec, Canada.   H3C 3J7                       


Newsgroups: gnu.utils.bug
From: ghazi@caip.rutgers.edu (Kaveh R. Ghazi)
Subject: textutils-1.3.6 regex.h line 399.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 20:30:46 GMT

	I was trying out textutils-1.3.6 from alpha.gnu.mit.edu and I had
trouble compiling it on a sun4 and a TekXD88/10 using the bundled C compilers.

	The problem is a bad cpp directive on line 399 of regex.h.  It is
fixed by the following one line change:


*** regex.h.BAK Fri Nov 20 20:51:33 1992
--- regex.h     Mon Jan 11 14:55:03 1993
***************
*** 396,402 ****
  #define _RE_ARGS(args) args
  #else /* not __STDC__ */
  #define _RE_ARGS(args) ()
! #if !const && !HAVE_CONST
  #define const
  #endif
  #endif /* not __STDC__ */
--- 396,402 ----
  #define _RE_ARGS(args) args
  #else /* not __STDC__ */
  #define _RE_ARGS(args) ()
! #if !defined(const) && !defined(HAVE_CONST)
  #define const
  #endif
  #endif /* not __STDC__ */

	This problem does not show up if you use gcc which is probably why
it slipped by you.

		--Kaveh
--
Kaveh R. Ghazi			CAIP Center, Rutgers University.
ghazi@caip.rutgers.edu		rutgers!caip.rutgers.edu!ghazi

Newsgroups: gnu.utils.bug
From: jwz@lucid.com (Jamie Zawinski)
Subject: make 3.62 installation
Organization: Lucid, Inc., Menlo Park, CA
Distribution: gnu
Date: Mon, 11 Jan 1993 11:41:01 GMT

I'd like to suggest that it be made possible to compile gnu make without
needing a working make to begin with.  Apparently Sun doesn't ship make
with minimal Solaris systems, so I lost.

No doubt I can find a Solaris binary somewhere, but still!

It shouldn't be too hard to write a script that will translate the existing
Makefile into a list of the commands necessary to do the first full compile.

	-- Jamie

Newsgroups: gnu.utils.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: configure
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 15:41:00 GMT

I found a strange bug in configure.  All lines like:

  err=`eval "$CPP $DEFS conftest.c 2>&1 >/dev/null"`

should be changed with:

  err=`eval "$CPP $DEFS conftest.c 2>&1"`

The error looks strange to me because it is so big, and it appears to
be present in all the FSF distributed software.  Am I overlooking
anything? 


One more thing: there is no way of specifying the man dir.  The
default one is not good for system V.

I am not part of this list, so please send the answers to me, too.
Thanks

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| +39-50-593203    (voice)

Newsgroups: gnu.utils.bug
From: urlichs@smurf.sub.org (Matthias Urlichs)
Subject: gdbm 1.5 loses key chain
Organization: Smurf-O-Box Karlsruhe, FRG
Distribution: gnu
Date: Mon, 4 Jan 1993 20:42:51 GMT

I'm using gdbm (1.5) and occasionally one of my gdbm files manages to 
mangle its database. The problem is that while the data are accessible
via gdbm_fetch(), a lookup through gdbm_nextkey() terminates without
returning the whole file.

Needless to say, this happens only if the database is heavily used;
thus, scanning the database after every access won't work.
Also needless to say, any mangled database contains confidential
information, so I can't post or mail it. Also needless to say, the
way I'm using the database absolutely depends on firstkey/nextkey
finding every record.

However, I am able to use a debugger. ;-)  Any gdbm experts out there
who can help shed some light on this, point me at places to search for
the problem, etc.? All database access goes through one program, which
can be hacked to death if necessary.

-- 
Darth Vader!  Only you would be so bold!
               -- Princess Leia Organa
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/

Newsgroups: gnu.utils.bug
From: ericb@lsid.hp.com (Eric Backus)
Subject: m4 version 1.0.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 22:55:29 GMT

I recently got m4-1.0.3.tar.Z from prep.ai.mit.edu.  I tried building
it on an HP 350 running HP-UX 8.0.  I did "./configure" followed by
"make".  The make failed when trying to create the "libm4.a" in the
"lib" subdirectory.  Output looked like this:


< Lots more stuff leading to this deleted >
        cd lib; make  CC='gcc' CFLAGS='-O2 -finline-functions -fomit-frame-pointer' LIBOJBS=''  RANLIB='ranlib' AWK='gawk' libm4.a
        gcc -c -O2 -finline-functions -fomit-frame-pointer  -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_TMPFILE=1 -DHAVE_EFGCVT=2 -I. obstack.c
        gcc -c -O2 -finline-functions -fomit-frame-pointer  -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_TMPFILE=1 -DHAVE_EFGCVT=2 -I. regex.c
        gcc -c -O2 -finline-functions -fomit-frame-pointer  -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_TMPFILE=1 -DHAVE_EFGCVT=2 -I. getopt.c
        gcc -c -O2 -finline-functions -fomit-frame-pointer  -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_TMPFILE=1 -DHAVE_EFGCVT=2 -I. getopt1.c
         cru libm4.a obstack.o regex.o getopt.o getopt1.o
Make: Cannot load cru.  Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.


I tried again, using GNU make rather than HP's make, and everything
worked correctly.

The cause of the problem appears to be that HP's make does not provide
a default value for the "AR" variable, while GNU make does.  Is this
something that "configure" could fix?
--
				Eric Backus
				ericb@lsid.hp.com
				(206) 335-2495

Newsgroups: gnu.utils.bug