bugmake - Bugs: bug #61171, Unexpected warning "Circular...

 
 

bug #61171: Unexpected warning "Circular test.mm <- test.mm.o dependency dropped."

Submitter:  None
Submitted:  Thu 16 Sep 2021 04:45:12 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 20 Sep 2021 04:30:31 PM UTC, comment #1: 

I'm not quite sure what the ask is here.  The behavior of make in this situation is correct: there is a built-in rule that specifies how to build any file "xxx" from any file "xxx.o", as you discovered.  It's standard that every prerequisite is also treated as a target and make will try to update it.  If you don't provide a way to update it, then make will use its built-in pattern rules, and of course if it finds a loop in the set of rules it will warn about this.

In general this situation is not a problem because it's extremely rare for a source file that gets turned into an object file to be named without any extension.  Virtually 100% of the time the source file will be something like "xxx.c" or "xxx.cpp" or similar, not just "xxx".

If the question is how to resolve this, you can either remove all built-in rules by adding the -r option to the make command line, or you can cancel this specific built-in rule by adding this to your makefile:


% : %.o


If you had a newer version of GNU make (the version 3.81 that comes with MacOS is >15 years old and known to contain bugs) you could also set "MAKEFLAGS += -r" inside the makefile to get rid of all built-in rules.

Paul D. Smith <psmith>
Group administrator
Thu 16 Sep 2021 04:45:12 PM UTC, original submission:  

Running `make` version 3.81 i386-apple-darwin11.3.0 on the `Makefile`:

```
test: test.mm.o
c++ -framework Foundation -o $@ $^
test.mm.o: test.mm
c++ -ObjC++ -c -o $@ $<
```

and having in place the following ObjectiveC++ source file `test.mm`:

```
#include <iostream>
#include "Foundation/Foundation.h"
int main() {
    NSLog(@"test");
    std::cout << "test\n";
}
```

results in the warning:

```
make: Circular test.mm <- test.mm.o dependency dropped.
c++ -ObjC++ -c -o test.mm.o test.mm
c++ -framework Foundation -o test test.mm.o
```

Invoking `make -p` reveals that there seems to be a build-in implicit rule for `pattern stem: `test.mm'` which could be the root cause.

The same behavior can be reproduced with an even simpler `Makefile`:

```
test.mm.o: test.mm
touch $@
```

Note that, e.g., the following `Makefile` executes without the warning:

```
test.mm.o: test.c
touch $@
```

provide any file named `test.c` is in place. Also the same `Makefile` with `test.c` replaced by `test.cc`, `test.cpp`, or `test.m` does not show a warning.

I do not know if the build-in implicit rule for `%.mm` mentioned above is intended like so. But even in case it is, it seems inconsistent with the ones for `%.c`, `%.cc`, `%.cpp`, `%.m`, which do not cause a circular dependency.

An obvious workaround is adding another target:

```
test.mm:
@echo "workaround"
```

or similar.

Thanks for looking into this if you find the time! And big thanks to all for your awesome work!

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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)
  •  

    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.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-20 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code