No, that is not how it works, like not at all.
Rust doesn't use the same concepts for building as C.
1. You don't build stuff with `rustc` in general. (You build it with cargo.)
2. You don't produce object files in general, sure rust can produce them and if you link something over the C-ABI it can make sense. What the compiler produces in general for linking libraries are rlibs.
3. rlibs are not just unstable in their format, they are more like a implementation details, don't expect to be able to link in a library as rlib. Like at all.
4. Rust widely uses generics similar to C++ templates this means part of the code which is not supposed to become public will leak if the libary interface involves templates/generics.
5. In rust (and somewhat in C) you normally don't link two "objects" to produce the final binary you build it with a number of "object" dependencies. But this doesn't work with what LGPL requires from you. It can be easy to make a public open-source skeleton you link in all LGPL libraries and your code then to make the linking magic work.
6. `rust --emit` is mainly meant for debugging, and some special use cases around embedding. Don't expect good integration with build tools.
And most important:
What is theoretically possible doesn't matter, what matters is what is practical. I.e. simple, and fast to setup and maintain.
Even for a C CI the requirements the static linking of a LGPL library puts up can make it easily not worth it.
> only that there is a way to patch
No, you need to be able to provide a non LGPL object which you can re-link with the LGPLed libary, so "just" binary patching isn't a legal option.
