HDTenEightyP/NetNews huggingface dataset:
From: cudcv@csv.warwick.ac.UK (Rob McMahon)
Subject: GDB 4.5 - Make problems on Sun3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 17:36:25 GMT

System is Sun3, SunOS 4.1, gcc 2.1

The prototype for sun3_saved_pc_after_call in tm-sun3.h doesn't have an
external declaration of `struct frame_info', and then clashes with its
definition.   That's not very well explained, but this shows the problem:

==============================================================================
Script started on Tue Apr 14 14:25:39 BST 1992
cudcv (41) >> make
make against=stage2 AR=ar AR_FLAGS=qc CC=gcc\ -O2 RANLIB=ranlib LOADLIBES= LDFLAGS= BISON=bison\ -y MAKEINFO=makeinfo RULE1=not-used RULE2=libiberty.a HOST_OFILES="`cat needed-list`" "CC=gcc -O2" "CFLAGS=-g -I. -I./../include " "AR=ar" "AR_FLAGS=qc" "RANLIB=ranlib"
make[2]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
make against=stage2 AR=ar AR_FLAGS=qc CC=gcc\ -O2 RANLIB=ranlib LOADLIBES= LDFLAGS= BISON=bison\ -y MAKEINFO=makeinfo subdir_do DO=all "DODIRS=doc"
for i in doc; do if [ -d ./$i ] ; then if (cd ./$i; make against=stage2 AR=ar AR_FLAGS=qc CC=gcc\ -O2 RANLIB=ranlib LOADLIBES= LDFLAGS= BISON=bison\ -y MAKEINFO=makeinfo DO=all DODIRS=doc "against=stage2" "AR=ar" "AR_FLAGS=qc" "CC=gcc -O2" "RANLIB=ranlib" "MAKEINFO=makeinfo" "BISON=bison -y" all) ; then true ; else exit 1 ; fi ; else true ; fi ; done
make[3]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
Glob doesn't work yet, but readline uses a piece of its src
gcc -O2 -c -g      -I. -I. -I./../include -I./../readline -I./vx-share  m68k-tdep.c
In file included from tm.h:19, from defs.h:659, from m68k-tdep.c:20:
tm-sun3.h:72: warning: `struct frame_info' declared inside parameter list
tm-sun3.h:72: warning: its scope is only this definition or declaration,
tm-sun3.h:72: warning: which is probably not what you want.
m68k-tdep.c: In function `sun3_saved_pc_after_call':
m68k-tdep.c:383: argument `frame' doesn't match function prototype
make[1]: *** [m68k-tdep.o] Error 1
make: *** [all-gdb] Error 1
41.740u 22.340s 4:15.03 25.1% 0+118k 76+1io 110pf+0w
Exit 1
cudcv (42) >> x
exit
Script done on Tue Apr 14 14:37:05 BST 1992
==============================================================================

I believe this is the correct fix ... 

==============================================================================
RCS file: tm-68k.h,v
retrieving revision 1.1
diff -c -r1.1 tm-68k.h
*** 1.1	1992/04/14 13:41:40
--- tm-68k.h	1992/04/14 13:43:42
***************
*** 321,326 ****
--- 321,331 ----
  #define FRAME_NUM_ARGS(val,fi) (val = -1)
  #endif
  
+ #ifdef __STDC__		/* Forward decl's for prototypes */
+ struct frame_info;
+ struct frame_saved_regs;
+ #endif
+ 
  /* Return number of bytes at start of arglist that are not really args.  */
  
  #define FRAME_ARGS_SKIP 8
==============================================================================

Cheers,

Rob

Newsgroups: gnu.gdb.bug
From: austin@frnk101.UUCP (Austin G. Hastings)
Subject: Is BFD support for Sun386's available?
Reply-To: austin@franklin.com
Organization: Franklin Electronic Publishers, Inc., Mt. Holly, NJ USA
Distribution: gnu
Date: Wed, 8 Apr 1992 14:24:43 GMT

We've just pulled gdb-4.4 and are trying to install it site-wide.

Aside from lacking heterogenous network support, the configure utility
works okay.  However, it reports that BFD doesn't support Sun Roadrunners
(Sun386's).

Before I go trying to cobble something together, has anyone already solved
this problem?  Does anyone have a set of files/patches/mantras which will
make gdb/BFD support the Roadrunners?

Email replies to reduce noise pollution.

-- 
-----------------------------------------------------------
Austin Hastings				austin@franklin.com


Newsgroups: gnu.utils.bug
From: erik@eab.retix.COM (Erik Forsberg)
Subject: Problem in sed.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 09:48:53 GMT

This was found using GNU sed 1.08 while
trying to build TeX 3.14 mf. I have simplified
the test case down to a minimum.

Take this sed program

: again
/\.$/{
	N
	s/\.\n/./
	t again
}
s/\.hh/.hhfield/g

Apply it to this input file

foo.hh.bar.
xyzzy

and the last s command is applied too many times.
The jump 't again' transfers outside of the currently executing
subprogram but that is not reflected in the sed execution.
At the jump, it jumps but does not exit the current invokation
of execute_program. So the final substitution happens, we return
from execute_program back to the original execute_program loop
that then applies the substitution again. We end up with the
text

foo.hhfieldfield.bar.xyzzy  instead of the expected
foo.hhfield.bar.xyzzy

I have currently NO idea how to fix it (without breaking anything else)

EF

---------------------------------------------------------------------------
Erik Forsberg, erik@eab.retix.com Phone: (310) 476-7133 FAX: (310) 476-7657


Newsgroups: gnu.utils.bug
From: rlk@think.com (Robert L Krawitz)
Subject: gmake 3.62
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 18:19:02 GMT

This code:

define stuff
	@echo; echo; echo Running examples for $d; echo
	-cd $d; $(MAKE) clean
	-cd $d; $(MAKE) run
	-cd $d; $(MAKE) clean

endef

examples:
	$(foreach d, $(DIRS), $(stuff))

does this:

gmake -v
GNU Make version 3.62, by Richard Stallman and Roland McGrath.
Copyright (C) 1988-1991 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.



Running examples for block-sparse

/bin/sh: -cd: not found
gmake[1]: *** No way to make target `clean'.  Stop.
/bin/sh: -cd: not found
gmake[1]: *** No way to make target `run'.  Stop.
/bin/sh: -cd: not found
gmake[1]: *** No way to make target `clean'.  Stop.
/bin/sh: @echo: not found

Running examples for block-tridiag

/bin/sh: -cd: not found
gmake[1]: *** No way to make target `clean'.  Stop.
/bin/sh: -cd: not found
gmake[1]: *** No way to make target `run'.  Stop.
/bin/sh: -cd: not found
gmake[1]: *** No way to make target `clean'.  Stop.
/bin/sh: @echo: not found

...

In 3.58, I believe that this worked.

Newsgroups: gnu.utils.bug
From: uddeborg@sisug.sisu.SE (G|ran Uddeborg)
Subject: make
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 18:54:07 GMT

I tried to make a number of dependencies using foreach and other
functions, but I failed because make obviously doesn't parse the
makefile in the order I'd expected.  If this qualifies as a bug or
not, I'm not sure.  Perhaps the documentation could clarify how
variables are expanded in this case, though.  I couldn't find it
there, but had to find out through experimentation.

Much simplified, I tried a Makefile looking like this:

	define deps
	apa: /usr
	bepa: /etc

	endef
	$(deps)

I hoped to make two dependencies this way, one for "apa" and one for
"bepa".  Turns out, however, that it interpretes it as a static
pattern rule, with the target-pattern containing the newline.  More
precisely, my make says

	Makefile:5: target pattern contains no `%'.  Stop.

This happened on

SunOS 4.1.2
SparcStation SLC
make 3.62

Newsgroups: gnu.utils.bug
From: jxt@stc06.ctd.ornl.gov (TOLLIVER J S)
Subject: Gnu make 3.62 breaking on HP 730 8.07
Reply-To: jxt@stc06.ctd.ornl.gov (TOLLIVER J S)
Organization: Oak Ridge National Laboratory
Distribution: gnu
Date: Tue, 7 Apr 1992 18:25:46 GMT

Since HP's make doesn't support VPATH, I just got and built GNU make, which
does support VPATH. Alas, something else is wrong but I'm not sure what.

I'm using HP's C++Softbench package for the C++ compiler. In it there is
a CC script that does a tiny bit of preprocessing before launching /usr/bin/CC.
Within that script there are the lines:

CC_prog=`/bin/basename $0`
new_path="`echo $PATH | /bin/sed -e
's:[a-zA-Z0-9_./-]*softbench/bin/*\:\{0,1\}::g'`"
real_CC=`PATH=$new_path /usr/bin/which $CC_prog | grep -v "^no "`

When running this script under the control of GNU make, the CC_prog and
new_path variables get set correctly but real_CC becomes NULL and an error
message:

to_short ran out of space.

appears.

With HP's make, all is well. Of course, I have to do some bit of
modification of the Makefile to get HP's make to get that far since it doesn't
know about VPATH. That modification is simple enough for a test, but quite
unacceptable when using this for real.

That error message is a bit bizzare. I cannot find the string "to_short" in
any of the gnu make 3.62 source files or in the outpout of strings applied
to the gnu make executable.

This has me stumped. And stuck -- until I can get it fixed. Any ideas?

Thanks,
Johnny Tolliver
jxt@ornl.gov

Newsgroups: gnu.utils.bug
From: crosson@cam.NIst.GOV (Robert Crosson)
Subject: Feature/bug in Gnu tar 1.10
Keywords: Gnu tar bug
Organization: National Institute of Standards and Technology
Distribution: gnu
Date: Tue, 14 Apr 1992 19:26:06 GMT

I have discovered what I think is a bug (feature?) in Gnu tar 1.10.
First of all, I'm running on Interactive's Unix (Sys VR3.2) version
2.2 on a 386-33 PC clone.  I compiled the tar source using gcc 1.40.
The tar program works in all other respects that I've tried.

The bug occurs when using the '-T' option.  I wrote a Bourne shell
script that does the following:

find <options> | sed -f <sed-script-file> | tar -cf - -T - > <filename>

When sed completes without producing any output, tar uses the current
directory as the place to start archiving data.  It's as if the '-T -'
hadn't been used and no file names or directories had been given.

I had expected tar to exit gracefully without generating any output in
these circumstances, but it didn't.  Is this a bug?

Bob Crosson
crosson@cam.nist.gov

Newsgroups: gnu.utils.bug
From: mjs@s4mjs.UUCP (M.J.Shannon)
Subject: cpio-1.5 bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 18:10:00 GMT

In building GNU cpio 1.5 on an ISC 386/ix v2.0.2 system, I discovered a
bug in the configure script.  I'm using GCC 2.1, and don't have bcopy.
However, when the script executes the test for bcopy, it compiles:

func=bcopy
main() { exit(0); ${func}(); }

Unfortunately, since the call to bcopy can't be reached (and GCC 2.1
knows that), the call is eliminated, and so there is no reference to the
symbol.  So I changed the compiled code to:

main(argc, argv) char**argv;{ if(argc==1)exit(0); ${func}(); }

And that correctly identifies that bcopy isn't found in any standard
library.

There is also another misfeature.  From Makefile.in:

OBJS = copyin.o copyout.o copypass.o dstring.o fnmatch.o global.o \
main.o util.o error.o getopt.o getopt1.o filemode.o version.o \
$(RTAPELIB) dirname.o idcache.o makepath.o xmalloc.o xstrdup.o \
@LIBOBJS@ @ALLOCA@ 

This works fine only if either @LIBOBJS@ or @ALLOCA@ is non-empty.
Otherwise, the backslash at the end of the previous line combined with
the space between @LIBOBJS@ and @ALLOCA@ confuses the system-supplied
make (I don't have GNU make yet).

Please acknowledge receipt of this message, as I'm not entirely sure
you'll receive it....

	Marty Shannon
--
--------------+ <Delapsus Resurgam: When I fall I shall rise. --(10cc)>
Marty Shannon | My opinions are just that.  You may share them.  No one
mjs@s4mjs.uucp| speaks for me, and I speak only for myself -- no matter
--------------+ where I post from.  Get it?		Post no flames.

Newsgroups: gnu.utils.bug
From: montnaro@moose.CRd.ge.COM (Skip Montanaro)
Subject: Make calls free during call to malloc
Reply-To: montanaro@crd.ge.com (Skip Montanaro)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 13:11:11 GMT

In the course of trying to identify some problems I am having executing
parallel actions (Make's -jN flag) on Silicon Graphics machines, I took the
opportunity to try out Purify on the Sun-4 version of make. It noticed that
free() was being called during a call to malloc. This occurs when a job
completes and the data structures for the child process are freed. Here is
an example traceback:

    Warning: calling free(1080696) while in a call
     to malloc/free/memalign.  Probably from a signal handler. 
     malloc/free/memalign are *not* reentrant and this may
     cause a later segv.
    This is occurring while in:
		 free_child (sun4_job.o; pc = 0x11a74)
		 child_handler (sun4_job.o; pc = 0x117e8)
		 _sigtramp (<shared library>; pc = 0xf7504c8c)
		 sbrk (purify.o; pc = 0x2b14)
		 ReAlLoC (<shared library>; pc = 0xf7507a94)
		 MaLlOc (<shared library>; pc = 0xf7507330)

The funny capitalization of malloc and realloc are Purify's doing. They are
the usual Sun versions of those functions. The sun4_job.o is also Purify's
work. It is really job.o.

I believe to correct this problem the best that can be done is to mark the
child's data structures as freeable and wait until later to free them.

I have no idea if this is the cause of my SGI problem, but I thought those
with the know-how and/or interest might want to look into this problem.

Skip (montanaro@crd.ge.com)

Newsgroups: gnu.utils.bug
From: djm@eng.umd.edu (David J. MacKenzie)
Subject: Re: Suggestions for fileutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 13:14:40 GMT

> This will be true in GNU as well, so it is fairly important to fix the
> documentation. 

>    The -f option is still useful for listing files in directory order
>    (unsorted) and since it only works on true directories there is no
>    longer any reason to turn off the -l, -s or -r flags (or any of the
>    others that -f needed to turn off before that didn't make it into
>    the man page).

> Further, this is an annoying misfeature.  I suggest that -f be
> redesignated "print in directory order", in other words, "don't sort",
> and that it should only interact with the flags that force sorting.

GNU ls doesn't have -f, because it doesn't seem useful to me, but it
has a -U (for "unsorted") option to suppress sorting.

Newsgroups: gnu.utils.bug
From: schwab@mouton.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Bug in pr (textutils 1.3)
Reply-To: schwab@ls5.informatik.uni-dortmund.de
Organization: University of Dortmund, Germany
Distribution: gnu
Date: Wed, 15 Apr 1992 13:09:38 GMT

pr doesn't count lines correctly in print_page()

diff -ur orig/pr.c ./pr.c
--- orig/pr.c	Sun Jan  5 23:40:06 1992
+++ ./pr.c	Wed Apr 15 15:08:11 1992
@@ -1149,7 +1149,7 @@
 
   lines_left = double_space ? 2 * lines_per_body : lines_per_body;
 
-  for (; lines_left > 0 && ready_to_print > 0; --lines_left)
+  while (lines_left > 0 && ready_to_print > 0)
     {
       output_position = 0;
       spaces_not_printed = 0;
@@ -1177,7 +1177,10 @@
 	}
 
       if (print_vertical_padding)
-	putchar ('\n');
+	{
+	  putchar ('\n');
+	  --lines_left;
+	}
 
       if (double_space && pvp && extremities)
 	{

--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de
---------------------------------------------------------------------------
Es besteht kein Grund zur Beruhigung -- Dieter Hildebrandt

Xref: sparky gnu.utils.bug:787 gnu.ghostscript.bug:428 comp.fonts:1263
From: Joseph.Francis@ircam.fr (Joseph Francis)
Newsgroups: gnu.utils.bug,gnu.ghostscript.bug,comp.postscript,comp.desktop,comp.fonts
Subject: Font sources (Re: volunteers to make fonts?)
Date: 6 Apr 92 15:20:51 GMT
Article-I.D.: ircam.1992Apr6.152051.668
Followup-To: gnu.utils.bug,gnu.ghostscript.bug,comp.lang.postscript,comp.desktop,comp.fonts
Organization: IRCAM, Paris (France)
Apparently-To: gnu-ghostscript-bug@inria.fr

In article <9204021715.AA20334@claude.cs.umb.edu> karl@cs.umb.edu writes:
>The GNU project needs to have a number of decent fonts for use with
>Ghostscript and TeX.  The plan is to do this by starting with scanned
>images of type specimens, converting the images to bitmap fonts, and
>then converting those bitmaps to outlines.
>
>We just released the first version of some programs (fontutils-0.4, on
>prep.ai.mit.edu) that implement this.  Now we are hoping some volunteers
>will help us actually produce the fonts.  We will supply the original
>scanned images to start from; you would run them through the programs.

I downloaded about 175 Postscript fonts from the ftp server
garbo.uwasa.fi (I assume there is an equivalent server on the US
side), which has some nice families (Frutiger, Bodoni, Peignot) and
some nice title fonts (Umbra, DomCasual, the blood-dripping
"PostCrypt" for example) though not all the fonts are of a high
quality. Are these not public-domain enough for the gnu project?
-- 
| Le Jojo: Fresh 'n' Clean, speaking out to the way you want to live
| today; American - All American; doing, a bit so, and even more so.
Newsgroups: gnu.utils.bug
From: jgp@moscom.COM (Jim Prescott)
Subject: Re: Suggestions for fileutils
Reply-To: jgp@moscom.com (Jim Prescott)
Organization: Moscom Corp., Pittsford, NY
Distribution: gnu
Date: Mon, 6 Apr 1992 20:02:16 GMT

In article <9204022129.AA07149@prism.CS.ORST.EDU> jacobsd@prism.cs.orst.edu
>(Dana Jacobsen (jacobsd@cs.orst.edu)) writes:
>  We're using the GNU fileutils here (just got 3.2) and like them a lot. 
>ls is missing the "-f" option:
>          -f   Force each argument to be interpreted as a directory
>               and list the name found in each slot.  This option
>               turns off -l, -t, -s, and -r, and turns on -a; the
>               order is the order in which entries appear in the
>               directory.

Note that -f doesn't work as documented on Suns anymore.  You can no longer
force something to be treated as a directory; getdents(2) cannot be coerced
into treating a file as a directory.

The -f option is still useful for listing files in directory order (unsorted)
and since it only works on true directories there is no longer any reason to
turn off the -l, -s or -r flags (or any of the others that -f needed to turn
off before that didn't make it into the man page).
-- 
Jim Prescott	jgp@moscom.com		{rit,tropix,ur-valhalla}!moscom!jgp

Newsgroups: gnu.utils.bug
From: blarson@cs.umb.edu (Bruce Robert Larson)
Subject: Re: strstr broken in gdb-4.4/libiberty -- fix included
Reply-To: Bruce R Larson <blarson%ires.com@cs.umb.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 09:01:23 GMT

I just sent in a bug report for strstr.c in gdb-4.4/libiberty.

After sending it, I discovered two things:
* I didn't update the external declaration of strcmp to strncmp
* the *patched* strstr doesn't return a pointer to the first string
  when the second string argument is NULL (it does not conform to
  the ANSI description).  

I'm including a new patch that solves both problems.

I'm also including a new version that I wrote that conforms
to the ANSI description and should be faster as well.  If you
decide to use my version, then please place it under the GNU
license.  The new version follows the corrected patch.


Bruce R Larson
blarson@ires.com
Integral Resources, Milton MA

--> first the corrected patch <--
*** ORIG/strstr.c       Mon Apr  6 21:12:57 1992
--- strstr.c    Tue Apr  7 03:53:15 1992
***************
*** 47,58 ****
    char *s1, *s2;
  {
    register char *p = s1 - 1;
    extern char *strchr ();
!   extern int strcmp ();

    while (0 != (p = strchr (p+1, *s2)))
      {
!       if (strcmp (p, s2))
        {
          return (p);
        }
--- 47,66 ----
    char *s1, *s2;
  {
    register char *p = s1 - 1;
+   register int len;
    extern char *strchr ();
!   extern int strncmp ();

+
+   if ( *s2 == '\0' )
+     return (s1);
+
+
+   len = strlen(s2);
+
    while (0 != (p = strchr (p+1, *s2)))
      {
!       if ( strncmp (p, s2, len) == 0 )
        {
          return (p);
        }


--> new version of strstr.c follows <--
/* strstr.c -- Bruce R Larson  April 7, 1992 */

# ifndef NULL
# define NULL 0
# endif

char *strstr(s1, s2)
    char *s1, *s2;
{
  register char c =*s2, *sp1, *sp2;


  if ( c == NULL )
    return s1;

  while(*s1)
    {
      if ( *s1 == c )
        {
          sp1 = s1; sp2 = s2;

          while( *sp2 != NULL && *sp1 == *sp2 )
            {
              sp1++; sp2++;
            }

          if ( *sp2 == NULL )
            return s1;
        }
      s1++;
    }

  return NULL;
}


Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: Suggestions for fileutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 06:28:12 GMT

   From: jgp@moscom.com (Jim Prescott)
   Date: 6 Apr 92 20:02:16 GMT
   References: <9204022129.AA07149@prism.CS.ORST.EDU>

   Note that -f doesn't work as documented on Suns anymore.  You can no longer
   force something to be treated as a directory; getdents(2) cannot be coerced
   into treating a file as a directory.

This will be true in GNU as well, so it is fairly important to fix the
documentation. 

   The -f option is still useful for listing files in directory order
   (unsorted) and since it only works on true directories there is no
   longer any reason to turn off the -l, -s or -r flags (or any of the
   others that -f needed to turn off before that didn't make it into
   the man page).

Further, this is an annoying misfeature.  I suggest that -f be
redesignated "print in directory order", in other words, "don't sort",
and that it should only interact with the flags that force sorting.

	-mib

Newsgroups: gnu.utils.bug
From: scott@ferrari.labs.tek.COM (Scott Huddleston)
Subject: GNU ld (1.94 beta) mishandles command file names
Reply-To: scott@crl.labs.tek.com
Organization: Computer Research Laboratory, Tektronix, Inc., Beaverton OR
Distribution: gnu
Date: Wed, 8 Apr 1992 23:28:33 GMT

gld (1.94 beta) doesn't parse command file names that contain ",".

Demonstrate by:

gld -T ,cmdfile
--
Scott Huddleston
scott@crl.labs.tek.com

Newsgroups: gnu.utils.bug
From: mtranle%caliph@icmv.UUCP (Minh Tran-Le)
Subject: Re: patches for fileutils-3.2 for aix ps/2
Reply-To: icmv!tranle%caliph@uunet.uu.net
Organization: IntelliCorp Inc.
Distribution: gnu
Date: Mon, 6 Apr 1992 16:57:30 GMT

After having posted my set of patches for fileutils-3.2 for aix ps/2,
I have found that the changes to src/du.c is not needed because my
changes to the macro convert_blocks in lib/system.h has already fixed
the non standard 4k blocksize returned by the aix ps/2 stat() function.

Minh Tran-Le.


Newsgroups: gnu.utils.bug
From: jtc@gain.com (J.T. Conklin)
Subject: Can GNU make remove *.o when using archives and explict dependencies
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 09:43:28 GMT

With the following Makefile:

>libfoo.a: 	libfoo.a(tar.o) libfoo.a(foo.o) libfoo.a(bar.o)

Gnu Make 3.62 will create libfoo.a from tar.c, foo.c, and bar.c; then
remove the *.o files automaticaly.

But if I add explicit dependencies to the makefile (so libfoo.a is
updated if tar.h, foo.h, or bar.h is changed),

>libfoo.a: 	libfoo.a(tar.o) libfoo.a(foo.o) libfoo.a(bar.o)
>
>tar.o: tar.c tar.h
>foo.o: foo.c foo.h
>bar.o: bar.c bar.h

Gmake no longer removes the *.o files.  Is there a way to get the same
behavior as with the implict dependancies, or do I have to add an `rm'
to the Makefile to clean up myself?




Newsgroups: gnu.utils.bug
From: crosson@cam.NIst.GOV (Robert Crosson)
Subject: Apology for multiple postings about Gnu tar
Organization: National Institute of Standards and Technology
Distribution: gnu
Date: Wed, 15 Apr 1992 12:22:59 GMT

I apologize for the multiple postings of the Gnu tar bug.  I thought
I was having problems with my news poster, but apparently all the
postings got through.  Again, I apologize for taking up bandwidth.

Bob Crosson
crosson@cam.nist.gov

Newsgroups: gnu.utils.bug