bugmake - Bugs: bug #31149, Rules to build -include makefiles...


bug #31149: Rules to build -include makefiles cause unexpected side-effects

Submitted by:  None
Submitted on:  Tue 28 Sep 2010 11:48:26 AM UTC  
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.82 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  Verified

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 15 Sep 2013 09:39:17 PM UTC, comment #2:

Looking at this again, the 3.82 output is the same as the 3.81 output and is correct. The reason is that when you add the explicit -include of Obj/test1.d that forces the target to be known to make, and make considers it to exist hence be a valid result of the vpath lookup.

Paul D. Smith <psmith>
Project Administrator
Tue 28 Sep 2010 01:28:33 PM UTC, comment #1:

The output you show here is actually the output you get when you use GNU make 3.81, not GNU make 3.82. And, this output is correct for the reasons I've described in response to your email to the bug-make mailing list.

However, your example does point out what appears to be a bug in GNU make 3.82. In 3.82 in a completely clean directory your makefile gives a different output; instead of succeeding it shows:

Looking at the debug and -p output, it seems that after we try and fail to build the Obj/test1.d file for the -include, somehow the prerequisite "test1.d" is changed to be Obj/test1.d which is wrong:

??!! Looking at the output of make -p for the above, I see:

??what?? Why is the prerequisite in the list here Obj/test1.d? It should just be test1.d.

So, although the original bug report is not valid (the makefile is not correct) and the example works as expected in GNU make 3.81, I'm leaving this open to track the unexpected behavior in GNU make 3.82.

Paul D. Smith <psmith>
Project Administrator
Tue 28 Sep 2010 11:48:26 AM UTC, original submission:

Steps to reproduce:
1. Unpack bug_0001.zip file (attached);
2. Execute makefile from archive on Linux platform. Result of operation:
> make
Creating dir Obj
Generate dependency for test1.cpp
Generate dependency for test2.cpp
Compiling test1.cpp
Compiling test2.cpp
Linking test.so
3. Remove file rm ./Obj/test1.o;
4. Execute makefile again. Result of operation:
Compiling test1.cpp
Linking test.so
5. Remove file rm ./Obj/test1.d;
6. Execute makefile again.

Expected result:
The dependency file generated by rule %.d;

Actual result:
make: *** No rule to make target `Obj/test1.d', needed by `test.so'.

Note: On Windows platform this case work properly.
On Linux it's work only if dependency files placed in current directory
and -include of dependency files written without $(addprefix ...).
Adding vpath %.d doesn't solve problem.



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

Attach Files:

Attached Files
file #21563:  bug_0001.zip added by None (932B - application/zip)


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-15 psmith StatusNone => Not A Bug
        Open/ClosedOpen => Closed
    2010-09-28 psmith Triage StatusNone => Verified
        SummaryThe rule for generation dependency file (%.d) doesn\'t work => Rules to build -include makefiles cause unexpected side-effects
    2010-09-28 None Attached File- => Added bug_0001.zip, #21563

    Back to the top

    Powered by Savane 3.3