glibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library.
However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time.
The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL.
I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.
If you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build.
All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.
Yeah, the embedded Linux context is messy. I don't know how the rules play out there (and I would be surprised if anyone truly knows). I thought we were talking about the general computing device use case.
Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.
However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time.
The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL.
I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.