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.
(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.
I 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
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.