> I see that rustc has a "--emit obj" option, from there surely any decent build system would allow enough customization to do what you want but there's enough raw capability to write a user guide that says "build your stuff with rustc --emit obj lgpl_lib_1.rs -o lgpl_lib_1.o and link with our proprietary .o with lld" ; and you'd be good to go.
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.
> You don't build stuff with `rustc` in general. (You build it with cargo.)
It doesn't matter in the slightest what you do, just that there is a documented way for someone to be able to do it, as convoluted as it may be. I should be able to patch your LGPL dependency even if I had never written a line of Rust in my life, so considerations like using the mainstream buildsystem there do not apply. A build.sh shell script is fine - I've used cmake to generate those for instance.
> 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.
Design your API boundaries better if you don't want that. Pimpl is often used for this.
> What is theoretically possible doesn't matter, what matters is what is practical. I.e. simple, and fast to setup and maintain.
.. no, what matters is respecting the license
> 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.
Sure, just ship the link line that cmake generates or whatever ? I don't understand what is so hard in that and it's more than enough to comply with LGPL.
> binary patching
I was referring of the standard process of applying a patch to the source code of a LGPL library before rebuilding it and linking it against the rest
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.