09.07.10, 17:36, "Craig James" <[email protected]>:
> On 7/8/10 10:17 PM, Andrew Dalke wrote: > > On Jul 7, 2010, at 10:36 AM, Paul Emsley wrote: > >>> The LGPL does not "know" of any difference between static linking and > >>> dynamic linking. In either method, the code "mixes" on the binary level. > >> > >> Agreed. > > > > That is incorrect. As Konstantin pointed out, LGPL requires that if > > the binary is distributed as a single executable (that is, using a > > static library) then the non-LGPL components must at least be available > > in object form so that people can relink it to modified versions of > > the library. > > If you're writing your own Makefiles, it's actually pretty easy to do this. > Just take whatever link instructions you have and leave out the LGPL library, > and you've got the two pieces. Then write another make(1) step that links > the two, and distribute the three pieces (makefile, library, and everything > else). > > If you're using cmake, you could trick it too. Cmake has a nice way to > separate the source from the build. I'll bet that once everything is > compiled and linked, you could simply replace all of the source references > with a link to one stand-in "source code" file that has a timestamp older > than when the build started, then just ship the entire build tree to the > customer. But this will require shipping build system to the user, which may be inappropriate. Also, shipped object files are easier to decompile than executable -- Regards, Konstantin ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Blueobelisk-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
