Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!violet.berkeley.edu!ilan343
From: ilan343@violet.berkeley.edu (Geraldo Veiga)
Newsgroups: comp.unix.sysv386
Subject: Re: Failure Compiling X386 1.1 on ESIX 3.2.D
Message-ID: <1991Mar6.022005.2721@agate.berkeley.edu>
Date: 6 Mar 91 02:20:05 GMT
References: <226@kalahari.cs.utexas.edu> <12870013@hpnmdla.hp.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 31

In article <12870013@hpnmdla.hp.com> darrylo@hpnmdla.hp.com (Darryl Okahata) writes:
>In comp.unix.sysv386, glenn@cs.utexas.edu (Glenn G. Lai) writes:
>>         make[2]: execve: /bin/sh: Arg list too long
>>
>> It was not the first time I'd encountered such a problem.  I switched from
>> /bin/make to GNU make 3.59, used GCC instead of cc, and tried sh, csh, and
>> bash, but the problem persisted.

>     I, too, had this problem.  The solution was to stop using both bash
>(exit bash completely!) and GNU make, and use /bin/sh and /bin/make.

This is a problem with gnu make,  but it can be fixed.  Gmake exports
all defined variables to the shell and runs out of environment space.

To avoid exporting Makefile variables you can do one of the following:

1. Name variables not to be exported with at least one non-alphanumeric
   character.

2. Define target ".NOEXPORT:" inside your Makefile. No variables will
   be exported, just like AT&T's make. This is a temporary kludge for
   gmake 3.59.  It will be replaced by a permanent solution in future
   releases.


I don't think bash has anything to do with this.  I had the
same problem with gmake + either ksh or sh.

By the way, I got the information above from Roland McGrath
(co-developer of gmake) in response to a similar query posted to
gnu.utils.bugs.