I've been through a lot of the LGPL questions here but haven't found this specific question. This is probably the closest to my situation: Dynamic linking LGPL library and licensing in Windows Store app
I'm building an application (free to download, but not open-source, in a fairly niche area of engineering) and would like to make use of an LGPL library (a Java library in this case). I'm not modifying the library in any way. The issue is that I need to release the application as a single statically linked executable using a proprietary third-party build tool. My understanding of the LGPL is that I need to be able to allow users to replace that library should they so wish.
Now I could provide the "object code" to my application, in a compiled form, but then a user would need to obtain this third-party build tool in order to rebuild the full application. As it happens there is a free-for-personal-use version of this build tool (free as in cost, not license), but I don't think that would properly comply with the LGPL.
As a solution, I could provide a "LGPL friendly" version of my application that just loaded the jar file from a directory at startup - I am assuming this would be compliant since the user can then replace the library jar with their own version. But there would be a performance loss (although functionality would be identical).
So two binary builds of my application - identical functionality, but only one variant would allow replacement of the LGPL libraries used.
Would this solution be considered acceptable? Are there any examples of this out there? Any pointers to documents that discuss this further?
apsillers answer is very informative, and helped me clarify my question a bit (I think)...
The library I'm dealing with is licensed under LGPL2.1, and section 6 states (in the context of being able to use a modified version of the library) :-
the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it
In my case, I deliver my application as a single .exe file (call this build A). In order for the user to re-link with a modified library and produce a new single exe they would need to download a closed-source tool "X" from a third-party vendor (and register with them in order to qualify for a free personal use license). "X" is not a general-purpose tool, nor included with any operating systems.
Along with "build A" I could also provide the same application as "build B", configured to load LGPL libraries from separate files.
Build "B" would be LGPL-compliant, but build "A" would not be. And I don't think that simply providing the two builds would migitate against A being a problem.
I think I need to try and keep the library jar outside my exe if possible.