Roger Fujii wrote:
If they are in separate files, and one calls the other via a function call that crosses process boundaries (i.e. uses a remote procedure call protocol), there is no linking, at least not by current standards (and I bet this will not change).
so, given that linux's threading model creates a separate process per thread,
It doesn't. It creates a new thread that happens to share address space with some other threads. The scheduler schedules threads, not processes. Perhaps it would be clearer if I said 'address space' instead of 'process'. (IBM is working on a new threading library that will make you happy, I think; it makes use of the "thread group" feature in the 2.4 kernel.)
Or in wine's case, you're going to make a distinction between server dlls and client dlls ONLY because they cross a process boundary?
Yes. A call that crosses an address space boundary by using a remote procedure call protocol is considered remote, and is neither static nor dynamic linking.
If you think this is ugly, try applying this to java, where the concept of "file" (since the classes can be in a zip file) an app (since there is no concept of an 'executable' - just entry points), or even a 'process space' is vague.
Replace 'file' with 'class' for java. That takes care of it, I think. I don't think we need to define application. If we did, 'hunks of executable code in the same address space/process', or a collection thereof, might do.
Header files for LGPL'd works are interesting; if they contain macros or inline functions, those need to be provided under a more liberal license, otherwise they would fit the definition of static linking.
section 5 is SUPPOSED to address this issue, but it depends on what people think "small" means.
Got it. I really should read the LGPL if I'm going to pontificate about it!
- Dan