Re: Extended Hamming encode/decode



steve_schefter@xxxxxxxxxxx wrote:
David Brown <david.br...@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

To use LGPL'ed code with your own code, anyone receiving your code must
have access to the LGPL'ed code, be able to change and recompile that
code, then link it along with the rest of the binary and run that
software instead. For non-embedded systems (or "big" embedded systems),
that typically means the LGPL'ed code is part of a dynamic library. To
use LGPL code in a (typically statically linked) embedded system means
that the end user will need access to your source code, or at least
compiled and linkable object files. Since that is impractical or
impossible for most embedded systems, the rough conclusion is that pure
LGPL code is very seldom suitable for embedded systems.

Okay, thanks. I guess where we differ is in the opinion that
dynamically linked apps are not suitable for embedded systems. The
ones I work on (Linux-based) tend to use dynamically linked apps more
than statically linked ones. In the early days, I've even had to
force the apps to be dynamically linked to fit everything in flash
(several apps linked with the same library).

Steve

I try to be careful to make the distinction between small statically linked embedded systems, where the (L)GPL is almost useless, and "large OS" embedded systems with dynamic linking, which often have LGPL and GPL code. But I don't always manage to make it clear.

So we don't actually differ in opinion at all.

mvh.,

David
.



Relevant Pages

  • Re: Extended Hamming encode/decode
    ... have access to the LGPL'ed code, be able to change and recompile that ... LGPL code is very seldom suitable for embedded systems. ... dynamically linked apps are not suitable for embedded systems. ...
    (comp.arch.embedded)
  • Re: Extended Hamming encode/decode
    ... LGPL code is very seldom suitable for embedded systems. ... dynamically linked apps are not suitable for embedded systems. ... (everything is compile-time selectable, so you can remove ... change to a #define and then a recompile. ...
    (comp.arch.embedded)
  • Re: Extended Hamming encode/decode
    ... LGPL code is very seldom suitable for embedded systems. ... dynamically linked apps are not suitable for embedded systems. ... (everything is compile-time selectable, so you can remove ... but sometimes you want that because RAM is scarse. ...
    (comp.arch.embedded)
  • Re: Extended Hamming encode/decode
    ... LGPL code is very seldom suitable for embedded systems. ... dynamically linked apps are not suitable for embedded systems. ... find an 8051 compiler/linkage editor that will support ... this sort of thing. ...
    (comp.arch.embedded)
  • Re: What are my options for dictionary hashing?
    ... stuff it's easiest to just recompile every time. ... If you can compile ... On embedded systems, all you need to do is to make sure the compilation is ... If you're stuck with a serial port as your umbilical, you're much better off with a cross-compiler, which only has to download the runtime object code, rather than passing all the source files through that slow pipe to a slow, limited on-board compiler. ...
    (comp.lang.forth)