mainmake - Support: sr #107487, MAKEFLAGS not being honored always...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

sr #107487: MAKEFLAGS not being honored always (regression) in 3.82

Submitter:  Dan McGee <toofishes>
Submitted:  Thu 30 Sep 2010 02:55:47 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Duplicate
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  POSIX-Based

Sun 18 Sep 2011 09:52:15 PM UTC, comment #4: 

Closing as a duplicate of bug #33873

Paul D. Smith <psmith>
Group administrator
Mon 07 Mar 2011 12:06:19 AM UTC, comment #3: 

I have a similar problem and it's too much of a coincidence not to be the same issue. It's definitely a regression in 3.82.

The testcase is the following (use the attached Makefile.test):
$ touch Makefile.test.in
$ MAKEFLAGS=n make -f Makefile.test

Expected output:
touch Makefile.test
echo This is a command with side-effect >&2

Actual output:
touch Makefile.test
This is a command with side-effect

Debugging the issue, I found out that the problem is the setting/resetting of MAKEFLAGS in connection to the re-execution of make after the Makefile is updated. An strace of the above execution shows that the following happens:

1) make detects that Makefile.test.in is newer than Makefile.in
2) make sets MAKEFLAGS to "w" and executes the command to update the Makefile:
  touch Makefile.test
3) make re-execs itself with the same command-line without resetting MAKEFLAGS. That is, MAKEFLAGS is still "w".

That means after step 3, the "n" flag has been lost and the echo command is actually executed, instead of just printed.

Note that this doesn't happen if you run: make -n -f Makefile.test. Like stated above in #3, the command-line is preserved in re-exec'ing.

I looked at Git's Makefile to see if it had a rule for updating the Makefile but I couldn't see one. Yet the symptoms are exactly the same: after the first execution, the symptoms disappear. The reason for that is that it's no longer necessary to update the Makefile.

(file #22846)

Thiago Macieira <thiagomacieira>
Thu 30 Sep 2010 05:05:04 AM UTC, comment #2: 

This is caused by the fix for https://savannah.gnu.org/bugs/?18124

Specifically, commenting out this addition in main.c "fixes" the issue:

/* Reset makeflags in case they were changed.  */         
{
  const char *pv = define_makeflags (1, 1);
  char *p = alloca (sizeof ("MAKEFLAGS=") + strlen (pv) + 1);
  sprintf (p, "MAKEFLAGS=%s", pv);
  putenv (p);
}


Looking into this, on the first run of make this code is exporting "MAKEFLAGS=" so define_makeflags appears to not be capturing the environmental variable.

The second run after aborting make works as expected as it does not go down that code path.

Allan McRae <allan>
Thu 30 Sep 2010 03:16:11 AM UTC, comment #1: 

I've attached some debug logs from a good and bad run. The most telling difference is the lack of the following from the bad run:

  • Need a job token; we have children
  • As well as some "Released token" messages


(file #21575, file #21576)

Dan McGee <toofishes>
Thu 30 Sep 2010 02:55:47 AM UTC, original submission:  

For some reason, the MAKEFLAGS environment variable is not working as expected in make 3.82. I appear to have found a fully reproducible test case when building git:

git clone git://git.kernel.org/pub/scm/git/git.git
cd git
export MAKEFLAGS='-j6'

make clean
make

Whenever you run 'make' here, it will not honor MAKEFLAGS and will build using only one core (monitored easily with top or a CPU monitor). If you interrupt and then rerun 'make', it will suddenly start using all cores. The key step here seems to be the 'make clean' - the call to 'make' immediately following this always runs without multiple jobs.

Confirmed NOT broken with make 3.81.

Config:

  • Arch Linux, 2.6.35-ARCH #1 SMP PREEMPT Tue Sep 21 09:22:09 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux

$ make --version
GNU Make 3.82
$ bash --version
GNU bash, version 4.1.7(2)-release (x86_64-unknown-linux-gnu)

Dan McGee <toofishes>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #22846:  Makefile.test added by thiagomacieira (94B - text/x-makefile)
file #21575:  bad_run.txt added by toofishes (3KiB - text/plain - Debug runs from a good and bad run)
file #21576:  good_run.txt added by toofishes (6KiB - text/plain - Debug runs from a good and bad run)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by thiagomacieira (Updated the item)
  • -email is unavailable- added by toofishes
  • -email is unavailable- added by toofishes
  • -email is unavailable- added by allan (Posted a comment)
  • -email is unavailable- added by allan
  • -email is unavailable- added by toofishes (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-18 psmith StatusNone Duplicate
        Open/ClosedOpen Closed
    2011-03-07 thiagomacieira Attached File- Added Makefile.test, #22846
    2010-10-20 toofishes Carbon-Copy- Added psmith
        Carbon-Copy- Added -email is unavailable-
    2010-09-30 toofishes Attached File- Added good_run.txt, #21576
        Attached File- Added bad_run.txt, #21575
    2010-09-30 allan Carbon-Copy- Added allan

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code