Which is why there's an explicit form of the GPL for libraries; the LGPL.
There still exists uncertainty and ways around it (You can execute GPL programs or write shell scripts so that GPL programs execute your code) such that you don't have to distribute the major parts of your codebase, but the GPL has an explicitly different version for libraries that are supposed to be linked in to non-free software vs libraries that are cores of GPL software.
My biggest objective criticism of the GPL licenses (i.e., not tied to whether it conforms to some ideology or other, but sticking to "mere" quality issues) is that they are all excessively tightly tied to the C runtime in how they are specified. It's reasonably clear to me what GPL and the LGPL mean in the world of C, but the more your runtime deviates from that, the more the license becomes a matter of interpretation. Arguably, nothing that isn't in C or C++ ought to be GPL'ed or LGPL'ed; even if you want to copyleft your code you arguably ought to use a different license that makes sense with regard to your code.
The FSF's interpretation of the GPL and LGPL has never made a distinction between static and dynamic linking. A lot of other armchair internet lawyers, make this distinction, though. ;-)
Eben Moglen seems to think, as I understand it, that it depends on how you distribute the thing. If you link dynamically but distribute the whole thing together as if it were a whole, it's a single work and all should be under the GPL. Other situations seem less clear.
This is the rub though. If you are (e.g.) distributing a desktop app that uses a LGPL library, you may not be able to assume that the library is installed on your target platform. For example, you may use libxml2 for XML parsing, but not be able to assume that it's installed on Windows (assuming for the sake of argument that libxml2 was LGPL instead of MIT licensed).
It's one thing to "cash in" on a GPL/LGPL project (e.g. writing a nice GUI around GnuPG, but not giving back to the project) where you are just wrapping the functionality of the GPL/LGPL project. It's another thing entirely to just use a support library (like an xml parser) where the library itself is not the main functionality of the program and have someone saying that your project has to be GPL.
That line of thinking goes both way. A game designer might need a supporting graphic library, but graphic itself is no the main function of the game. The developer just want to wrap the functionality of the library, yet the license of the game is now dictated by the graphic library. Releasing the whole work under a open license would be piracy.
Same problem exist with complete overhaul mods to game. Counter strike simply wrapped around half-life. Half-life was not the main function of CS, yet if they had been giving out CS with half-life under a open license it would again be piracy.
Thus it is hard to see a world where copyright would allow someone to ignore the license as long the "library" is not the main functionality. It would be a nice world, a world with remixing and a explosion of creativity, but a very different world from one that we got now.
There still exists uncertainty and ways around it (You can execute GPL programs or write shell scripts so that GPL programs execute your code) such that you don't have to distribute the major parts of your codebase, but the GPL has an explicitly different version for libraries that are supposed to be linked in to non-free software vs libraries that are cores of GPL software.