Static linking in LGPL, Upgrading LGPL libs
in [Embedded]
|
Prev: Call for Papers: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010
Next: Lab-Standard 49-Port USB Hub
From: David Brown on 7 Feb 2010 16:15 Michael Schnell wrote: > On 07.02.2010 18:16, David Brown wrote: > >> ucLinux has no problem with shared libraries: > > Not uClinux itself, but the gcc for some architectures just doesn't > support it. > But can you run ucLinux on those architectures? For example, you can't generate position independent code with gcc for the AVR, but that's because there is no natural way to run PIC on that architecture, and very few practical uses of it if there were (and you certainly can't run ucLinux on it, being an 8-bit cpu). Have you any examples of ucLinux on architectures where gcc cannot generate PIC?
From: Nobody on 7 Feb 2010 17:59 On Sun, 07 Feb 2010 05:44:39 -0800, Karthik Balaguru wrote: >> With static linking, things are a little more complicated. However, you >> do not have to make your own code available to the end user in a "nice" >> form - it is enough that they can re-link with their modified library. >> Thus you can provide it as linkable object code, or perhaps obfusticated >> source code. > > I have many queries here - > > I think only linkable object code is enough. Won't linkable > object files alone serve the purpose ? Why should the > source code be provided to the end-user ? Linkable object files are sufficient. The LGPL (v2.1) specifically lists one of the options as: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) Version 3 goes further for a "User Product", including a more general requirement that you provide sufficient information to enable the user to replace the combined work (e.g. if the device requires firmware updates to be digitally signed, you have to provide a suitable signing key). > If source code is mandatory, You only have to provide source code for the library, not for your own code which is not derived from the library. > can you pls elaborate how > can obfusticated code appear ? Is the method of > providing obfusticated approved by LGPL ? Obfuscated source code is not considered source code by the LGPL or GPL: "Source code" for a work means the preferred form of the work for making modifications to it. IOW, source code would be the form that you actually use; an intermediate form isn't sufficient, even if it compiles to the same object code. > I wonder why LGPL has such a strange policy > as LGPL was to help the closed source softwares > by providing them LGPL'ed libraries so that they > need not reveal the source code, even though > the free software community was also indirectly > enjoying the benefits from LGPL. It seemed to > be a gain for both the communities. What's strange about it? One of the fundamental principles of the GPL and LGPL is that the user is entitled to modify the code. If you provide a statically-linked binary, the user is unable to modify any of it, even the LGPL parts.
From: Nobody on 7 Feb 2010 18:10 On Sun, 07 Feb 2010 13:55:12 +0100, Michael Schnell wrote: > On 07.02.2010 17:44, Karthik Balaguru wrote: > >>> I wonder why LGPL has such a strange policy > > I suppose they just did not consider statical linking... They certainly did. The LGPL specifically addresses both dynamic and static linking, saying (roughly) that if you don't use dynamic linking, you need to provide "linkable" object code. The point is that the user has a right to use a modified copy of an LGPL'd library in place of the original.
From: Paul Keinanen on 8 Feb 2010 00:41 On Sun, 07 Feb 2010 12:10:21 +0100, Michael Schnell <mschnell_at_bschnell_dot_de(a)aol.com> wrote: >On 07.02.2010 11:40, Karthik Balaguru wrote: >> But, Why does it not support for dynamically >> linked libraries ? Just eager to know the reason >> for not supporting dynamic linking. > >The compiler needs to support this. The dynamically linked (shared) >libraries need to be loaded into a free spot in memory and at compile >time you can't know where to find this and without an MMU you can't >create a predefined address space for the library. In the context of licensing, there is typically only a single instance of a single program. > >One way of doing shared libraries is "PIC" (Position Independent Code). >Not all compilers for all architectures support this. The PIC is useful, if there are several libraries from various vendors, but when the libraries are from a single vendor, it should be easy to link each library to a fixed and publicly known start address. Typically a function start address table is loaded at that address, followed by the actual library routine codes. When linking the main program, reserve the space required by the library and provide small stub routines to perform an indirect indexed jump through the jump table (which is in a publicly known address). >or shared libraries not only the code needs to be position independent, >but also static data needs to be unique for each program linking the >library dynamically. If the library needs to be used from more than one program, then it needs to be reentrant, i.e. all modified variables must be in the stack of the calling program. For architectures that do not easily support stacks, the library code may require some program instance ID parameter, so that the library can use different data sets for each program.
From: karthikbalaguru on 8 Feb 2010 08:45
On Feb 8, 3:59 am, Nobody <nob...(a)nowhere.com> wrote: > On Sun, 07 Feb 2010 05:44:39 -0800, Karthik Balaguru wrote: > >> With static linking, things are a little more complicated. However, you > >> do not have to make your own code available to the end user in a "nice" > >> form - it is enough that they can re-link with their modified library. > >> Thus you can provide it as linkable object code, or perhaps obfusticated > >> source code. > > > I have many queries here - > > > I think only linkable object code is enough. Won't linkable > > object files alone serve the purpose ? Why should the > > source code be provided to the end-user ? > > Linkable object files are sufficient. Thats great :-) > The LGPL (v2.1) specifically lists one of the options as: > > a) Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever > changes were used in the work (which must be distributed under > Sections 1 and 2 above); and, if the work is an executable linked > with the Library, with the complete machine-readable "work that > uses the Library", as object code and/or source code, so that the > user can modify the Library and then relink to produce a modified > executable containing the modified Library. (It is understood > that the user who changes the contents of definitions files in the > Library will not necessarily be able to recompile the application > to use the modified definitions.) > Interesting ! Good snapshot of the relevant section of the license . > Version 3 goes further for a "User Product", including a more general > requirement that you provide sufficient information to enable the user to > replace the combined work (e.g. if the device requires firmware updates to > be digitally signed, you have to provide a suitable signing key). > Okay . > > If source code is mandatory, > > You only have to provide source code for the library, not for your own > code which is not derived from the library. > > > can you pls elaborate how > > can obfusticated code appear ? Is the method of > > providing obfusticated approved by LGPL ? > > Obfuscated source code is not considered source code by the LGPL or GPL: > > "Source code" for a work means the preferred form of the work for > making modifications to it. > > IOW, source code would be the form that you actually use; an intermediate > form isn't sufficient, even if it compiles to the same object code. > > > I wonder why LGPL has such a strange policy > > as LGPL was to help the closed source softwares > > by providing them LGPL'ed libraries so that they > > need not reveal the source code, even though > > the free software community was also indirectly > > enjoying the benefits from LGPL. It seemed to > > be a gain for both the communities. > > What's strange about it? One of the fundamental principles of the GPL > and LGPL is that the user is entitled to modify the code. If you provide a > statically-linked binary, the user is unable to modify any of it, even the > LGPL parts. Karthik Balaguru |