3 ms·
You might want to provide separate CFLAGS and LDFLAGS. Also, I prefer adding -MMD to CFLAGS instead of having an additional rule for dependency generation: Thi
by cygx 14y ago
You might want to provide separate CFLAGS and LDFLAGS.
Also, I prefer adding -MMD to CFLAGS instead of having an additional rule for dependency generation: This way, you won't unnecessarily trigger dependency generation on targets which do not build objects like clean.
- mjschultz 14y ago(Sorry, I misread the above post, but I believe LDLIBS is the Makefile built-in variable for libraries to link.) Actually, in this case, I believe LDLIBS would be more appropriate since the OP isn't passing any flags to `ld` but rather the libraries for `ld` to link. I ended up getting hit be this in a simple Makefile a few weeks ago that worked in Fedora but failed in Ubuntu. The target was "%.o: %.c", which make auto-expands to be (something like): $(CC) $(CFLAGS) $(LDFLAGS) $@ $^ $(LDLIBS) But I had placed the libraries in LDFLAGS, instead of LDLIBS which caused Ubuntu to fail at finding a function in one of the libraries. Moving the libraries to LDLIBS solved the problem.
- cygx 14y agoI was more concerned about passing CFLAGS when linking - he already has a LIBS variable; you're right that the 'canonical' name for his LIBS variable is LDLIBS (as well as LOADLIBES - anyone an idea where that name came from?). EDIT: stop editing your answer while I'm writing my own ;) According to the manual, the built-in rule for linking an executable `n` from a single object file is $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)