HDTenEightyP/NetNews huggingface dataset:
From: stesan@stesan.AUto-trol.COM (Stephen Sanford, Jr.)
Subject: execve problem on Aegis
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 19:33:03 GMT

A developer just discovered a problem using GNU make on the Apollo,
with Aegis SR10.3.5 operating system.  (We tried both version 3.59 and 3.62.7
of GNU make.)

One of his targets includes a system directive to rm all of the object
files in a directory.  GNU make prints out the expanded version of the
rm command, and then errors out, saying

gmake: execve: /bsd4.3/bin/rm: Arg list too long
gmake: *** [clean_all] Error 127

The execve man page on the Apollo machine explains this error:

     [E2BIG]
                     The number of bytes in the new process' argument list is
                     larger than the system-imposed limit.  The limit in the
                     system as released is 10240 bytes (NCARGS in
                     <sys/param.h>.

Since the arg list was larger than 10240 bytes, execve failed, so gmake
errored out.

Has anyone devised a workaround to avoid this problem?  Or are we stuck with
having to alter our makefiles to keep argument lists short?

Thanks for any help...
*********************************************************
Steve Sanford, Jr.       Auto-trol Technology Corporation
stesan@auto-trol.com              12500 N. Washington St.
(303) 252-2016                     Denver, CO  80241-2400

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: bison 1.19 info typo: `@noindex'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 21:44:15 GMT

The texinfo file distributed with bison 1.19 has a typo that causes `make
bison.info' to fail.  I'm using the latest public version of texinfo (texinfo
1.15, which contains makeinfo 1.47).  Here are the symptoms:

	makeinfo ./bison.texinfo
	Making info file `bison.info' from `./bison.texinfo'.
	./bison.texinfo:4512: Unknown info command `noindex'.

Here's a patch:

===================================================================
RCS file: bison.texinfo,v
retrieving revision 1.19
diff -c -r1.19 bison.texinfo
*** bison.texinfo	1992/06/22 04:18:26	1.19
--- bison.texinfo	1992/09/28 21:39:21
***************
*** 4509,4515 ****
  bison /debug/name_prefix=bar foo.y
  @end example
  
! @noindex
  is equivalent to the following command under POSIX.
  
  @example
--- 4509,4515 ----
  bison /debug/name_prefix=bar foo.y
  @end example
  
! @noindent
  is equivalent to the following command under POSIX.
  
  @example

Newsgroups: gnu.utils.bug
From: dgr@eng.vitalink.COM (Daniel Robinson)
Subject: gas support for 29k
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 08:34:51 GMT

Is the AMD 29k on the list of processors that you intend to support
with future releases of gas?

Thanks,

Daniel

Newsgroups: gnu.utils.bug
From: lwv26@cas.ORG (Larry W. Virden, x2487)
Subject: Typo ? in regex 0.11 README ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 13:44:02 GMT

The README file in version 0.11 of regex refers one to an INSTALL file
for details of installation, then goes on in the next sentence and says
that only the info file gets installed.  I assume that regex.o should
be installed in the gnu libc and the regex.h should be installed in the
gnu include directory?  Without an INSTALL I am uncertain.
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com

Newsgroups: gnu.utils.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Oops: Improvements for patch 2.0 12g8
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 15:23:45 GMT

Sorry, the patch i posted was wrong. Here is the complete patch again:

Here is a patch to patch which i find very useful: when backing up the
patched file, automagically make the necessary directories. This
allows e.g.:

patch -B orig/ < patchfile

without worrying about directories to be created.
I also added code for systems having the mkdir system call, so that it
isn't necessary to call mkdir via system().

diff -ur orig/config.h.in ./config.h.in
--- orig/config.h.in	Fri Jul 10 23:33:33 1992
+++ ./config.h.in	Tue Oct  6 14:18:57 1992
@@ -6,6 +6,9 @@
 /* Define if the system has strerror().  */
 #undef HAVE_STRERROR
 
+/* Define if the system has mkdir().  */
+#undef HAVE_MKDIR
+
 /* Define if the system has ANSI C header files and library functions.  */
 #undef STDC_HEADERS
 
diff -ur orig/configure.in ./configure.in
--- orig/configure.in	Tue Jul 14 08:40:33 1992
+++ ./configure.in	Tue Oct  6 13:59:29 1992
@@ -16,7 +16,7 @@
 AC_UNISTD_H
 AC_USG
 AC_REPLACE_FUNCS(rename)
-AC_HAVE_FUNCS(strerror)
+AC_HAVE_FUNCS(strerror mkdir)
 AC_ALLOCA
 AC_LONG_FILE_NAMES
 AC_XENIX_DIR
diff -ur orig/util.c ./util.c
--- orig/util.c	Tue Sep 15 04:04:31 1992
+++ ./util.c	Tue Oct  6 14:14:37 1992
@@ -91,7 +91,10 @@
 	if (debug & 4)
 	    say3("Moving %s to %s.\n", to, bakname);
 #endif
-	if (rename(to, bakname) < 0) {
+	if (rename(to, bakname) < 0
+	    && (errno != ENOENT
+		|| (makedirs (bakname, TRUE),
+		    rename (to, bakname) < 0))) {
 	    say4("Can't backup %s, output is in %s: %s\n", to, from,
 		 strerror(errno));
 	    return -1;
@@ -337,6 +340,7 @@
     if (dirvp < 0)
 	return;
 
+#ifndef HAVE_MKDIR
     strcpy(buf, "mkdir");
     s = buf;
     for (i=0; i<=dirvp; i++) {
@@ -351,6 +355,20 @@
     }
     if (s != buf)
 	system(buf);
+#else
+    for (i = 0; i <= dirvp; i++)
+      {
+	struct stat sbuf;
+	if (stat (tmpbuf, &sbuf))
+	  {
+	    if (errno != ENOENT || mkdir (tmpbuf, 0777))
+	      return;
+	  }
+	else if (!S_ISDIR (sbuf.st_mode))
+	  return;
+	*dirv[i] = '/';
+      }
+#endif
 }
 
 /* Make filenames more reasonable. */
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.utils.bug
From: trq@dionysos.thphys.ox.ac.uk
Subject: textutils 1.3: sort does not clean up after itself
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 10:32:40 GMT

Sort does not clean up after itself if it gets a SIGPIPE.  This can be
demonstrated by compiling this program:
#include <stdio.h>
main()
{
   int i;
   for(i = 0; i < 100000; i++)
      printf("%d\n", i);
}
After running it and directing the output to a file "tst.sort", the
command "sort tst.sort | more", followed by a "q" to exit more will
leave files around in /tmp as evidenced by the command:
ls -l /tmp/s*
-rw-r--r--   1 trq      staff       87194 Oct  3 11:11 /tmp/sort1823800001
-rw-r--r--   1 trq      staff       98304 Oct  3 11:11 /tmp/sort1823800002
-rw-r--r--   1 trq      staff       98304 Oct  3 11:11 /tmp/sort1823800003
-rw-r--r--   1 trq      staff       98304 Oct  3 11:11 /tmp/sort1823800004
-rw-r--r--   1 trq      staff       98304 Oct  3 11:11 /tmp/sort1823800005
-rw-r--r--   1 trq      staff       43878 Oct  3 11:11 /tmp/sort1823800006
-rw-r--r--   1 trq      staff       64602 Oct  3 11:11 /tmp/sort1823800007

This is for sort in textutils-1.3 compiled with gcc 2.2.2 on a Sun
Sparcstation ELC running SunOs 4.1.1.  Config.status reads:
DEFS=" -DSTDC_HEADERS -DHAVE_UNISTD_H -DSTRERROR_MISSING"
LIBS="-lmalloc"
CC="gcc"
INSTALL="/bin/install -c"
INSTALLDATA="/bin/install -c -m 644"
RANLIB="ranlib "
LIBOBJS=" memcmp.o stpcpy.o"
ALLOCA=""

The problem is that SIGPIPE is not caught and handled.  A sample patch
to fix this is below.

Tom Quinn        Theoretical Physics, University of Oxford
Internet: 	 trq@dionysos.thphys.ox.ac.uk
JANET:    	 trq@uk.ac.ox.astro
Phone:		 44-865-273956

===================================================================
RCS file: RCS/sort.c,v
retrieving revision 1.1
diff -c -r1.1 sort.c
*** 1.1	1992/10/03 10:11:49
--- sort.c	1992/10/03 10:12:36
***************
*** 1456,1466 ****
--- 1456,1471 ----
    sigaction (SIGHUP, NULL, &oldact);
    if (oldact.sa_handler != SIG_IGN)
      sigaction (SIGHUP, &newact, NULL);
+   sigaction (SIGPIPE, NULL, &oldact);
+   if (oldact.sa_handler != SIG_IGN)
+     sigaction (SIGPIPE, &newact, NULL);
  #else				/* !_POSIX_VERSION */
    if (signal (SIGINT, SIG_IGN) != SIG_IGN)
      signal (SIGINT, sighandler);
    if (signal (SIGHUP, SIG_IGN) != SIG_IGN)
      signal (SIGHUP, sighandler);
+   if (signal (SIGPIPE, SIG_IGN) != SIG_IGN)
+     signal (SIGPIPE, sighandler);
  #endif				/* _POSIX_VERSION */
  
    gkey.sword = gkey.eword = -1;

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM ( Marty Leisner)
Subject: questions on fileutils-3.3/cp
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Wed, 30 Sep 1992 19:14:24 GMT

GNU cp has a lot of nice features (particular the -a and -update options).

I'm somewhat comfused about copying trees of directories to back up.

It seems when I execute:
cp -a srcdir targetdir

if targetdir doesn't exist, it makes it (i.e.
cp -a test1 test2)
After test2 exists, and I execute the command again, it puts
test1 under test2 (i.e. test2/test1).

In addition, if I do:
cp -a /homes/leisner/tmp/test1 test2
it works as
cp -a test1 test2 (when I'm in /home/leisner/tmp).

This is confusing and needs to be documented.

Also, it looks like it makes sense to have a translation table of uid and gid
for cp.  This is so when I execute cp as root, and do an update, I can copy
distributions and map UID/GID from one domain to another domain.  Sound useful?
Looks like I'm going to do it.

I did a study of copying between machines, and using NFS with cp -a -update
wins...seems to be the simplest I've seen.


Marty    leisner.henr801c@xerox.com 
          Member of the League for Programming Freedom 
 The Feynman Problem Solving Algorithm:
 1) Write down the problem
 2) Think very hard
 3) Write down the answer     -- Murray Gell-mann

Newsgroups: gnu.utils.bug
From: marc@cam.org (Marc Boucher)
Subject: find-3.7
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 06:21:31 GMT

Here are the necessary changes to build find-3.7 on 386BSD 0.1.

Essentially:
	- a system re_comp() is declared in <unistd.h> and collides with yours.
	- _sysconf() isn't implemented yet.

-- 
^@-------~~--**----/ --- - Marc Boucher
marc@CAM.ORG \----?	":
/-----_--  -    ----_|| +1 514 466 8932 - &-

--- 1.1	1992/10/06 06:03:59
+++ find/parser.c	1992/10/06 06:04:23
@@ -23,7 +23,9 @@
 #include <grp.h>
 
 #ifdef HAVE_UNISTD_H
+#define re_comp XXre_comp
 #include <unistd.h>
+#undef re_comp
 #endif
 
 #if defined(USG) || defined(STDC_HEADERS)
--- 1.1	1992/10/06 06:05:11
+++ find/pred.c	1992/10/06 06:05:38
@@ -21,7 +21,9 @@
 #include <sys/stat.h>
 
 #ifdef HAVE_UNISTD_H
+#define re_comp XXre_comp
 #include <unistd.h>
+#undef re_comp
 #endif
 
 #include <pwd.h>
--- 1.1	1992/10/06 06:00:51
+++ lib/regex.c	1992/10/06 06:02:13
@@ -46,7 +46,9 @@
 #else  /* not emacs */
 
 #ifdef HAVE_UNISTD_H
+#define re_comp XXre_comp
 #include <unistd.h>
+#undef re_comp
 #endif
 
 #if defined (USG) || defined (POSIX) || defined (STDC_HEADERS)
--- 1.1	1992/10/06 06:09:32
+++ xargs/xargs.c	1992/10/06 06:10:22
@@ -128,7 +128,7 @@
 #include <unistd.h>
 #endif
 
-#ifdef _POSIX_VERSION
+#if defined(_POSIX_VERSION) && !defined(__386BSD__) && !defined(BSDI)
 #ifdef ARG_MAX
 #undef ARG_MAX
 #endif /* ARG_MAX */

Newsgroups: gnu.utils.bug
From: schrod@iti.INformatik.TH-darmstadt.DE (Joachim Schrod)
Subject: Re: Configure [was: tar 1.11]
Organization: TU Darmstadt
Distribution: gnu
Date: Sat, 26 Sep 1992 19:19:46 GMT

In article <9209151900.AA05495@geech.gnu.ai.mit.edu>, mib@gnu.ai.mit.edu (Michael I Bushnell) writes:
>    Date: Tue, 15 Sep 92 07:42:26 EDT
>    From: pinard%icule.UUCP@Larry.McRCIM.McGill.EDU (Francois Pinard)
>    Reply-To: pinard@iro.umontreal.ca
> 
>       Configure should correctly figure out the options to use, or it has
>       a bug.  You should never need to edit the Makefile produced by GNU
>       programs which come with configure.
> 
>    These statements look quite strong to me, too strong in fact!  I would
>    certainly never expect `configure' to discover all peculiarities and
>    strangenesses of all systems and installations.
> 
> If a program cannot be completely configure by autoconf, then other
> things need to be done.

Ok, then here is the bug report for the $n+1$st time (it has been
reported in this forum more than once):

On HP/UX (both version 7.x and 8.0x) alloca() must not be taken from
libPW.a, but the supplied alloca.c must be used.
    In fact, on HP/UX 7.x libPW.a should be used *with great care*,
it contains brain dead code. (I haven't checked for 8.x, since I use a
replacement... ;-)

As long as this is not checked during the configuration process,
HP/UX users must edit a configure-made Makefile by hand. What's needed
are hints files, like in Larry Wall's Configure.

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany

Newsgroups: gnu.utils.bug
From: rrh@tera.com (Robert R. Henry)
Subject: .//foo.h bug in make-3.62 and predecessors
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 22:41:26 GMT

When make-3.62 (and predecessors) uses this Makefile

hello.o: hello.c .//hello.h
	gcc -c hello.c -o hello.o

with local files named 'hello.c' and 'hello.h', gmake reports that
  gmake: *** No way to make target `/hello.h'.  Stop.

now then, .//hello.h is the same file as ./hello.h, which is the same
as hello.h.

sounds like some name normalizer is screwing up.

-rrh

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM ( Marty Leisner)
Subject: vh 1.4
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Mon, 28 Sep 1992 01:15:16 GMT

I'm trying to run vh (the hyptertext viewer for the jargon file).

version 1.4 on prep doesn't have a version number (just vh.tar.Z).

When I compile it on a sun for BSD, it doesn't seem to work right.
(it has problems with curses).


It would be most useful if I could find a precompiled version for ms/dos.

Marty    leisner.henr801c@xerox.com 
          Member of the League for Programming Freedom 
 The Feynman Problem Solving Algorithm:
 1) Write down the problem
 2) Think very hard
 3) Write down the answer     -- Murray Gell-mann

Newsgroups: gnu.utils.bug
From: hts@coulomb.eng.ohio-state.edu (The ElectroScience Pendejo)
Subject: Suggestion for cpio...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 16:38:30 GMT

   Hello gnu people....


   I love the gnu cpio program. One feature I would like to see (if possible
   in the future) would be the use of both the -t and -r flags, so that I
   could see what is going by (I suppose unconditionally), then rename based
   on a regexp. The rational is to allow me to see if the stuff on that cpio
   archive is from the correct workstation (in my case).

   Perhaps I will poke around more in the sources; it should be an easy mod.
   It saves having to find the correct archive on an 8mm tape, then backing
   up! 

   thanks again for all the great code

   harry


Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: Defining make program requirements
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 12:47:53 GMT

    Should one assume that if the package is a GNU package that gnu make is
    going to be required to make it?

No.

     others seem to
    depend on GNU make without specifying.

That's wrong; if it doesn't specify, then any make should work, and you
should report a bug.

    gcc -O -o regex  dregex.o printchar.o upcase.o xmalloc.o alloca.o test.o bsd-interf.o other.o tregress.o psx-basic.o psx-extend.o psx-generic.o psx-group.o psx-interf.o psx-interv.o main.o
    ld: Undefined symbol
       start
       _re_exec
       _re_comp
       .udiv
    ld: entry point not in text
    collect: /usr/bin/ld returned 2 exit status

Well, re_exec and re_comp should be in bsd-interf.o.  Are they (check
with nm)?  start and .udiv missing sounds like something is wrong with
the loader, but I'm afraid I wouldn't know where the problem might be.
Maybe gcc -v would help you isolate the problem.

   because the regex.info files were not rebuilt .

They shouldn't be rebuilt; the .info that come with the distribution
should be up-to-date.

    I cannot tell if I am having a package problem or if it has to do with a gcc
    or gnu make configuration problem.

I don't see anything that suggests the linking problem is due to GNU
make vs.  Sun's make ... it sounds like a gcc installation error in one
way or another, but that's just a guess.  (I didn't get the error with
SunOS 4.1.1/GCC 2.2.2/GNU make 3.62.)  I don't see anything else that
looks like an error.

Newsgroups: gnu.utils.bug
From: lwv26@cas.ORG (Larry W. Virden)
Subject: Re: Defining make program requirements
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 11:02:49 GMT

It APPEARs the problem is that the fellow who tried to install glibc was
unsuccessful - during his installation something core dumped and his
attempts to get that package to deinstall itself failed - so he was
trying to deinstall by hand - which of course had lots of other
ramifications.  Thanks for your notes though.  I didn't find out about
our problems until late yesterday... I THOUGHT everyone here had
indicated that everything was installed correctly :-( ...

-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com

Newsgroups: gnu.utils.bug
From: jbotz@orixa.mtholyoke.edu (Jurgen Botz)
Subject: tar-1.11.1 omission: logfile.sed
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 17:55:54 GMT

The level-? scripts included with the tar package are quite nice... but
the sed script that's supposed to process the logfile before sending to
the administrator is not included in the distribution.  (Could someone
mail me a copy?)

--
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: wiesel@ipf.bau-verm.uni-karlsruhe.DE (Joachim Wiesel)
Subject: Re: Anyone compiled shellutils-1.7 on SunOS 4.1
Reply-To: wiesel@ipf.bau-verm.uni-karlsruhe.de
Organization: IPF, University of Karlsruhe
Distribution: gnu
Date: Tue, 6 Oct 1992 09:20:14 GMT

In article AA14616@cas.org, lwv26@cas.ORG (Larry W. Virden, x2487) writes:
>If anyone has built shellutils version 1.7 on a Sun, would you drop me an
>email ?  I am having problems getting the lib directory to compile.
>
>I am getting the following:
>gcc -O -c -g  -DHAVE_LIMITS_H=1 -DHAVE_SYSLOG_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_FTIME=1 -DHAVE_UT_HOST=1 -DHAVE_C_LINE=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_TM_ZONE=1 -DDIRENT=1 -I. strtoul.c
>In file included from /projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stdlib.h:10, from ./strtol.c:33, from strtoul.c:21:
>/usr/include/sys/stdtypes.h:27: redefinition of `size_t'
>/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:82: `size_t' previously declared here
>/usr/include/sys/stdtypes.h:28: redefinition of `ptrdiff_t'
>/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:45: `ptrdiff_t' previously declared here
>/usr/include/sys/stdtypes.h:30: redefinition of `wchar_t'
>/projects/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/include/stddef.h:120: `wchar_t' previously declared here
>gmake[1]: *** [strtoul.o] Error 1
>making all in src
>gmake[1]: *** No way to make target `../lib/libshu.a'.  Stop.
>making all in man
>gmake[1]: Nothing to be done for `all'.

This is caused by erroniously defining 'size_t, prtdiff_t and wchar_t' in <sys/stdtypes.h> in SUNOS 4.1.x. There is an excellent article on this by
Rainer Klute in the IX/Magazine 10/92 pp.124.
I'll summarize:

Copy /usr/include/sys/stdtypes.h to your gcc tree include directory.
(e.g: /usr/local/lib/gcc-lib/sparc/2.2.2/include/sys in our case)
Delete  the lines:
....
typedef int             size_t;         /* ??? */
typedef int             ptrdiff_t;      /* result of subtracting two pointers */
 
typedef unsigned short  wchar_t;        /* big enough for biggest char set */
....
from the copy.

Add #include <stddef.h> to the copy of <sys/stdtypes.h> before the very first
line of this file, e.g.:
....
#include <stddef.h>
#ifndef __sys_stdtypes_h
#define __sys_stdtypes_h
....


That's it.

Joachim

 */
#include <stddef.h>
#ifndef __sys_stdtypes_h
#define __sys_stdtypes_h
 
---

Joachim Wiesel, Institut fuer Photogrammetrie und Fernerkundung,
Universitaet  Karlsruhe, Englerstr. 7, D-7500 Karlsruhe, Germany
Phone: +49 721 608 2316                      Fax: +49 721 694 568
Internet: wiesel@ipf.bau-verm.uni-karlsruhe.de


Newsgroups: gnu.utils.bug
From: lwv26@cas.ORG (Larry W. Virden, x2487)
Subject: Defining make program requirements
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 13:51:50 GMT

Should one assume that if the package is a GNU package that gnu make is
going to be required to make it?  Some packages tell me, others seem to
make just fine with other brands of make while still others seem to
depend on GNU make without specifying.

For instance, I am using SunOS 4.1.2, gcc 2.2.2 and gnu make 3.62 .  When
I try to make regex 0.11 by saying make all, I get a series of compile
statements, then the error:

gcc -O -o regex  dregex.o printchar.o upcase.o xmalloc.o alloca.o test.o bsd-interf.o other.o tregress.o psx-basic.o psx-extend.o psx-generic.o psx-group.o psx-interf.o psx-interv.o main.o
ld: Undefined symbol
   start
   _re_exec
   _re_comp
   .udiv
ld: entry point not in text
collect: /usr/bin/ld returned 2 exit status
gmake[1]: *** [regex] Error 1
gmake: *** [all] Error 1

If I try to just say gmake without an argument, I get an attempt to generate
regex.dvi and then the message:

gmake[1]: Nothing to be done for `default'.

Finally, if I type gmake install, I get
$  gmake install
for d in doc test; do (cd $d; gmake  CPPFLAGS='' CFLAGS='-g' CC='gcc -O' DEFS='-DSTDC_HEADERS=1 -DUSG=1' LDFLAGS='' LOADLIBES='' install); done
mkdir /projects/gnu/sun4 /projects/gnu/sun4/info
mkdir: /projects/gnu/sun4: File exists
mkdir: /projects/gnu/sun4/info: File exists
gmake[1]: *** [install] Error 1 (ignored)
for i in *.info*; do /bin/install -c -m 644 $i /projects/gnu/sun4/info/$i; donegmake[1]: Nothing to be done for `install'.

because the regex.info files were not rebuilt .

I cannot tell if I am having a package problem or if it has to do with a gcc
or gnu make configuration problem.  Does anyone have any insights?
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: bug in 2.2.2?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 20:16:46 GMT

These insn patterns must always have a predicate.

Newsgroups: gnu.gcc.bug