> 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

> 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