Re: dynamic versus statically linked libraries
Circa 2000-Jun-02 07:22:17 -0500 schrieb gk4@us.ibm.com:
: I had the impression that it was an LSB requirement to statically link a
: library if it is not in the LSB specification;
As i recall, we discussed this some at the face-to-face meeting in
December. The phrasing we ended up using was that the LSB-compliant
application would have to "carry any non-LSB libraries around with
itself". This certainly allows statically linking such libraries where
that's also permitted by the library's license, but does not require
it. It's also possible to install dynamically linked libraries in,
say, /opt/vendor/app/lib/ (or even /opt/vendor/lib/), and use
LD_LIBRARY_PATH or LD_PRELOAD to link with the libraries at runtime.
: however, that would not be practical for most *PL licensed libraries.
: Here are the axioms that I understand, and #7 is causing me problems
: because of #3.
:
: 1) If I have an *PL or private application that dynamically or statically
: links a GPL library, then it becomes GPLed. See FSF's
: http://www.gnu.org/copyleft/gpl.html section 2b.
s/becomes/must be/
: 2) If I have an *PL or private applicaiton that dynamically links an LGPL
: library, then it retains original licenses. See FSF's
: http://www.gnu.org/copyleft/lesser.html section 5.
s/retains/may retain/
: 3) If I have an *PL or private applicaiton that statically links an LGPL
: library, then it becomes LGPLed. See FSF's
: http://www.gnu.org/copyleft/lesser.html section 4.
s/becomes LGPLed/must be LGPLed or GPLed/
: 4) If I have an LSB compliant application that dynamically or statically
: links an LSB compliant library, then it remains LSB compliant.
:
: 5) If I have an LSB compliant application that dynamically or statically
: links a non-LSB compliant library, then it is no longer LSB compliant
: because of its dependency.
I am guessing that you intend "a non-LSB compliant library" to mean "a
library which is specified by LSB but does not comply with the
specification", in which case [5] is probably correct.
: 6) If I have an LSB compliant application that dynamically links an LSB
: compliant library that is not part of the LSB specification, then it is no
: longer LSB compliant because of its dependency.
I'm not sure what you mean by "an LSB compliant library", but i suspect
you mean "a library which uses only uses facilities provided by itself
or specified by LSB". In that case, [6] is only true if that library
is a system library. If the library is installed as "part" of the app,
then the app may link to it dynamically.
: 7) If I have an LSB compliant application that statically links an LSB
: compliant library that is not part of the LSB specification, then it
: remains LSB complaint.
This is actually part of [6].
: Given the axioms above, then a private (non *PLed) application cannot use
: *any* LSB compliant *PLed library that is not in the LSB specifiction,
: because #7 would force the private application to become *PLed.
s/force/require/
: To correct this, then axiom #7 should be dropped and #6 should allow the
: LSB compliant application to remain LSB compliant.
That's the intent that i understood out of the December meeting all
along.
Obviously, if your interpretation and mine differ, then this ought to
be documented somewhere. If not in the spec, then in a set of written
guidelines for applying the spec (the LSB-Specification-HOWTO?).
--
jim knoble | jmknoble@jmknoble.cx | http://www.jmknoble.cx/
Reply to: