Let me just clarify one point because probably that got lost in translation.
Suppose that you are building *closed* source software A using the library B that is covered by the LGPL license. Two main cases exist:
1. You create your application A *without* modifying library B: *no problem*, this is the most common case (e.g., all the applications compiled with g++ and using the STL library coming with it, as the GNU STL is released under LGPL).
2. You create your application A and you need to *modify* library B (let's call the modified version B') and, as a consequence of this, you need to statically compile B' into A or to distribute the shared library B' with A: you need to make your changes available to *anyone* requesting them as the LGPL states explicitly that. You can distribute them under request, distribute the source together with the binary of A or made them available on a webpage and pointing to it in the documentation of A. This would mean that you are actually creating a "fork" of B.
If, in case 2, you fail to comply with providing the B', that is not a *moral* problem but a *legal* one: licenses are legal contracts and you can be taken to court if you fail to comply.
What *usually* happens, if you need to create B' out of B, is to contribute back your changes to B. This not only for some ideological reasons but also because it has a positive effect on *your* work as well: if you do *not* merge your changes from B' into B, every time that B gets new patches and improvements you have to port them to your custom library in order to benefit from them. Moreover, merging your changes from B' into B can improve them at *no cost* for you because more people can contribute to them with fixes, etc.
Now, if to create A, you need to modify so *heavily* B that afterwards it will not even be recognizable, why using B in the very first place and complicate your life?
My £0.02
Typed on a very small keyboard...