> IANAL, but is not obvious to me at all after from reading the LGPL.
I'm not either, but you should probably take another look at LGPL v2.1 section 6, which is the section giving you the additional right to create a combined work under a license other than LGPL (eg proprietary).
The first paragraph makes clear that you get these rights iff you follow the rest of paragraph 6. It then makes some requirements about the licence of the combined work. It says nothing of what the user must be able to do, only what you must not forbid the user to do.
The second paragraph deals exclusively with copyright notices, entirely irrelevant to this case.
6a makes a series of requirements ending with "then relink to produce a modified executable". It says nothing about putting said executable on any particular hw.
6b does implicitly assume that the user is able to install a modify library. There seems to be different legal opinions if you can fulfil this paragraph if you ship your software on hardware where the user is not able to do so, but that is irrelevant, as 6b is an *optional* *alternative* to 6a. If you do follow 6a you can completely ignore 6b.
6c through 6e gives you optional alternatives as to when and how to provide the 6a and 6b requirements, entirely irrelevant to this case.
The next paragraph deals with the tools needed to *generate* the executable. It says nothing about the tools needed to putting said executable on any particular hw.
The last paragraph only states that you can't avoid fulfilling the requirements above because of a different license makes contradicting demands.
To conclude, in some embedded systems you might have a problem fulfilling 6b (depending on legal interpretation), but if you provide the object files (or source code) to the non-LGPL'ed parts together with the source code to the LGPL'ed parts you are fulfilling 6a, so 6b is of no issue.