[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Robert Sachunsky]

Follow-up Comment #9, bug #44853 (project make):

related/duplicate: #45763

I would like to add that (to my surprise) even the workaround offered by the
file function (and specifically documented for this purpose in section 8.6 of
the manual, with example recipes) _may not work_:


program: $(OBJECTS)
 $(file >$@.in,$^)
 $(CMD) $(CMDFLAGS) @$@.in
 @rm $@.in


It seems like the reason for me was that the makefile contained an *export*
directive (for all variables), which causes *OBJECTS* getting appended to the
envp of the execve call of the recipe. Since E2BIG is caused by _either_ the
argv _or_ the envp argument, the result is the same (just the error message is
confusing).

So as long as make has no general solution for E2BIG, I recommend at least
documenting that *.EXPORT_ALL_VARIABLES* or *export* will break the file
function workaround.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Paul D. Smith]

Follow-up Comment #7, bug #44853 (project make):

No automated conversion of the command is going to work: you point out csh
(which shouldn't be used with make actually) but what if SHELL is Perl?  Or
Ruby?  Or...

If you're going to introduce a new variable anyway, it seems like it would be
more straightforward to introduce an alternative to SHELLFLAGS that is used
when make decides to create a batch file, rather than a variable containing a
source operation.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Daniel Richard G.]

Follow-up Comment #8, bug #44853 (project make):

SHELL=perl:

.SHELLSOURCE = require $(.SHELLSCRIPT);

SHELL=ruby:

.SHELLSOURCE = require $(.SHELLSCRIPT)

If SHELL doesn't have an include/source directive, then there's a
challenge---but no worse than the E2BIG.

One issue with using a construct that is parallel to .SHELLFLAGS rather than
additive is that if you add e.g. -e to .SHELLFLAGS, then the parallel form
won't necessarily pick it up.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Daniel Richard G.]

Follow-up Comment #6, bug #44853 (project make):

Well, it would be possible to transform

$(SHELL) -c very long command

into

[write very long command to /tmp/long.sh]
$(SHELL) -c . /tmp/long.sh

so mucking around with .SHELLFLAGS is unnecessary.

The syntax for sourcing a script may vary (e.g. csh would use source rather
than .), but a new variable could be provided to control that, like

.SHELLSOURCE = . $(.SHELLSCRIPT)
.SHELLSOURCE = source $(.SHELLSCRIPT)

Would this address your concerns?

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Paul D. Smith]

Follow-up Comment #5, bug #44853 (project make):

This is not so easy.  Make has exactly one way to invoke an interpreter today:
essentially '$(SHELL) $(.SHELLFLAGS) recipeline  The setting of .SHELLFLAGS
is geared towards this configuration.

Many/most interpreters require a different set of flags to process a file than
they do to process a script via the command line, and there is no facility in
make today that would allow one to provide those alternative flags.  It's not
enough to just assume you can remove the -c option and call it good.  Any
solution to this problem would need to provide a solution to this aspect as
well.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Daniel Richard G.]

Follow-up Comment #3, bug #44853 (project make):

I'm afraid this is a project using Automake-generated makefiles, and it has to
support non-GNU Make programs. If I had full control over the rules, I could
certainly go a different route.

(This issue will, in fact, likely require a companion bug to be filed in
Libtool. As I found using this hack, even if Make doesn't choke executing that
very long command, the interpreter running the libtool script will.)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Daniel Richard G.]

Follow-up Comment #4, bug #44853 (project make):

I have filed the bug report against Libtool:

http://debbugs.gnu.org/20632

Libtool can handle overlong object lists capably, but the generated Make rule
in its current form will not allow it.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[David Boyce]

Follow-up Comment #2, bug #44853 (project make):

Given that you already have GNU make 4.1, any chance you can use the new
$(file ...) function
(http://www.gnu.org/software/make/manual/make.html#File-Function) to do the
same thing in your own recipe? It could be a path of much less resistance.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

[Daniel Richard G.]

URL:
  http://savannah.gnu.org/bugs/?44853

 Summary: gmake: execvp: bash: The parameter or environment
lists are too long.
 Project: make
Submitted by: iskunk
Submitted on: Thu 16 Apr 2015 05:37:23 AM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

I am attempting to build a project on AIX 4.3.

The makefile is specifying a library target that has a large number of objects
(1000+). GNU Make prints the (very long) command that it is about to execute,
but then, it returns

gmake: execvp: bash: The parameter or environment lists are too long.
Makefile:16554: recipe for target 'libfoo.la' failed
gmake: *** [libfoo.la] Error 127

This is with GNU Make 4.1, and GNU Bash 4.3.30.

I suspect that GNU Make is passing the recipe command as a direct argument to
bash -c, which then exceeds the system's limits on execvp(). What is
probably needed is to place the command in a temporary file, and then pass
that file to the shell for execution.




___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44853

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make