Find a open source project to support. Get familiar with the code base and the community. Write a patch, send it, get it refused, work with the community, finally getting your patch in.
See, it's not that hard learning "C" and becoming a "C developer"... 21 days at most!
External libraries are a reality in any programming language. The popular ones that come with your OS of choice are likely very well documented. You don't need to understand the preprocessor, compiler, assembler, and linker to use them. In fact, I'd argue that for most programming you only need to know how to invoke the compiler as the rest of the steps are already automated. K&R C will teach you enough about how to use header files to be able to use external libraries.
A debugger is useful, but something like gdb is not necessary to write C. In fact, I'd say Valgrind is far more useful, and once again, it'll take 20 minutes to learn.
As for supporting open source projects, why start there? Do you learn Python and immediately jump to submitting patches to Django? No, you write your own code and learn from that. Same here, as you are presumably learning C/JavaScript/Ruby/Erlang/CL/etc. to use it, not to add a line to your resume that you are a contributor to some open source project.
No, you won't become an expert developer in 21 days. But since C is such a small language with so few features I'd argue that learning how to use it is more about getting the memory structure right in your head than about learning syntax. By comparison, Python (my primary language lately) has many more types and constructs to worry about.
Autotools has a steep learning curve and makes a good deal of project maintainers nervous because it's not obvious how it works and it's diffult to cut through all the abstraction steps to figure out what-goes-where. CMake is usually a pretty good alternative to figuring out m4 scripts with autotools. CMake is usually faster too.
Valgrind is good but it doesn't work on all platforms and it again needs more examples and howtos.
Dtrace too could also use some more blog howtos.
Powerful tools need to be both clearly and succinctly explained and sufficiently configurable in order to be widely usable. The clear conveyance of system behavior should be a top priority for code and supporting documentation.
All I'm saying really: Learning C is easy, becoming a halfway decent C programmer is hard.