Those don't seem like "these days" things. In fact, some is much more "old days".
Glib is just another library like any other, and POSIX is just a library plus specification of the details any platform would have to specify. And if you're not on something that tries hard to look like a *nix, POSIX mastery isn't going to help you.
Autotools is a plague slowly being eradicated, the problems it ostensibly solved have become far less serious to the point that they can be effectively dealt with by less insane means.
Make is increasingly replaced or supplemented with other tools (cmake, scons, ninja, ant if you're crazy), especially when builds start getting complex.
Heavy macro usage is not some modern idiom. In fact, "these days" it's indicative of laziness, poor design, premature optimization, or a religious refusal to use an OO language for OO code. Sadly there is a lot of this code out there, but yours doesn't have to be part of it. If writing your application involves many and/or complex macros, you should reconsider your approach.
I wouldn't regard POSIX as "just another library". It is the interface between your program and the operating system. In order to gain a healthy understanding of things like memory mapping, signals and process control, you have to go beyond the corresponding man pages.
Most higher level languages do have wrappers around these calls, but you rarely have to worry about things such as async-signal-safety or EINTR, for example. Knowing why such things are problematic isn't of much interest to the average Python programmer, while essential for writing correct and safe C code.
I wasn't talking about "higher level languages", really. Still, you have made a strange statement. Most obviously, if you don't worry about EINTR in Python, your code crashes. This was, in fact, the subject of a recent draft PEP (475) that generated a fair bit of discussion but not much consensus.
To the extent you're better off in Python or any other high-level language than in C, it's because things are removed from your control. Obviously, if you can't do something in a language, you can't do it wrong. That is uninteresting.
And of course EINTR and much signal behavior is POSIX-specific -- as in, you may not even have it (or necessarily anything like it) on other platforms. This, again, is not a "C" thing.
You make an excellent point. Perhaps more so than with other languages, getting to grips with making C actually useful relies a lot on quite extensive knowledge of the build environment.
You also have to know about how computers work, how they represent numbers, how and where they store memory, how computers process information, you have to know about interrupts low level os stuff, networking protocols, physical hardware limitations, debugging low level byzantine failures. You have to know a lot more than just C syntax. I haven't even mentioned computer science, best practices, working with others, architecture and UI topics.
It's not only the build environment. Mastering C goes way beyond the superficial level of just learning the language and the libraries. Being a very thin abstraction over the machine, you will inevitably encounter some quirks which can only be explained from the perspective of a compiler writer or a hardware designer. Also, POSIX is not just another library, it's the interface between your program and the operating system. Knowing what to call and how to call it ultimately requires a good foundation in OS theory.
How is knowing useful libraries for C any different to knowing useful library for other languages? Perl (about the only other language I have any experience with) seems to be dependant on modules which you struggle to compile through cpan.
Learning C these days means mastering Make, autotools, macros, POSIX and Glib.
Knowing these is the difference between your contrived linked-list example and creating software that can actually be deployed and is useful.