Static linking in LGPL, Upgrading LGPL libs

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I have been trying to use certain
LGPL based libraries. I understand
that if it is dynamically linked, there
is no problem . I understand that If
the library code is changed, then the
library source code has to be
released. But if a person does a static
linking of the library, it is not clear if
the source code of the application
has to be given.

I searched the internet and got few links.
http://answers.google.com/answers/threadview/id/439136.html
Though it discusses about static linking
in LGPL,  it does not arrive at a definite
answer !

Should the person need to give the
object files of the entire source code ?

Should a person need to give the source
or linkable objects files that load the
static libraries alone and not the whole
closed source code ?

How is the LGPL library upgrade handled
if it is statically linked with an
application(closed source) ?

Both the GPL and LGPL mandate that
if any modifications are made to the
GPL/LGPLed code directly should be
released under the respective licenses.

I think LGPL is popular compared to GPL
because LGPL provides the freedom to link
with any project. GPL allows dynamic
linking alone. GPL allows static linking
but with a condition that the source
code that uses the library statically
should be placed under GPL :-(.

On continuing my search, i came
across the below link -
http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
Lets go to the section 6 titled 'The
orgins of Linux and LGPL'.
It seems to convey that the LGPL
allows proprietary code to be linked
to the GNU C library, 'glibc' while
conveying the advantages of LGPL
over GPL. But does not explicitly
convey the method of linking. Since
it is mentioned in the advantages
point, it can be assumed that it is
static linking. The next statement
conveys that the source code need
not be released but should the
person release the object files ?
It does not give definite informatioin.

So,
Is static linking of LGPL libraries
allowed ? If Yes, How ? Should
i need to release any part of the
closed source code or library ?
Should i need to release the closed
source software object files or only
the library based object files ?
Any ideas ?

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

Same here and seemingly everywhere ;)

The wording of LGPL seems to require that LGPL coded needs to be
upgradeable by the end user. Thus to allow for this with statically
linked projects, the source code of the complete project needs to be
available to the end user.

Are the .h files that come with e.g the dynamically linked libc not
released as LGPL ? How to upgrade those ? I don't think anybody ever
intended them to only be used with open source software.

OTOH, I never found a single notice that LGPL holders requested
programmers to open their code for that upgradeablility reason.

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 7, 1:35A0%pm, Michael Schnell
Quoted text here. Click to load it

If the source code of the complete project needs to be
given to the end user , then how is it different from GPL ?

Wasn't LGPL introduced so that the proprietary
software can use the free library features instead
of opting for other alternative libraries that provide
similar feature ? Wasn't it indirectly saving the
free softwares ?

From one of the link in internet, i understand
that incase a library provides a unique capability
and there is no competitor, then that library might
be released under GPL so that it would bring in
the GPL terms to the application using it and
thus that application will be available freely
just because it has to use that unique library.

Quoted text here. Click to load it

I think, if it is dynamically linked, there is no
problem either for upgradation.

Quoted text here. Click to load it

Interesting ! Does this hold true even
for closed source applications that statically
liked the LGPL libraries ? Any ideas ?

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

It doesn't. You just completely blew out the context. The context was
the case where the binary is only available statically-linked to the
library and provides no way to replace it. In that one specific case,
then you have to give the source code the complete statically-linked
object.

But you can also make the program available both statically-linked and
dynamically-linked. Or you can make the program available only
dynamically-linked to the library. Or you can make it available
statically-linked, but with hooks so it can (at run time) use a
dynamically-linked version instead. Or you can ship the object files
so the user can link it to a different version to make a new
statically-linked version. Or a million other things.

Quoted text here. Click to load it

Yes.

DS

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

You can't if the build system does not allow for dynamically linked
libraries. This is the case with many (embedded) uCLinux Architectures.

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
On Feb 7, 2:35A0%pm, Michael Schnell
Quoted text here. Click to load it

Interesting !!
But, Why does it not support for dynamically
linked libraries ? Just eager to know the reason
for not supporting dynamic linking.

Okay, But, I am really interested to know if the
application linking the LGPL library statically
should release the application source code also.
So,continued to explore the licenses, and i got
the below statements for LGPL from the link :-
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_ =
from_the_GPL

-------------
"Essentially, if it is a "work that uses the library",
then it must be possible for the software to be
linked with a newer version of the LGPL-covered
program. The most commonly used method for
doing so is to use "a suitable shared library
mechanism for linking".
Alternatively, a statically linked library is allowed
if either source code or linkable object files are provided."
--------------

In the above extract, does the term 'source code'
in the last line refer to the obfuscated source code ?

Thx in advans,
Karthik Balaguru

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

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.

One way of doing shared libraries is "PIC" (Position Independent Code).
Not all compilers for all architectures support this.

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.

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

ucLinux has no problem with shared libraries:

<http://www.ucdot.org/article.pl?sid03%/11/25/1126257

Life is often /easier/ with statically linked libraries on ucLinux
systems, and static linking is often more efficient - shared libraries
have an overhead in disk/flash space, ram, and run-time.  So unless you
really are sharing them a lot, or need to update them independently,
static linking is smaller and faster.  On small embedded Linux systems,
you have only a few programs running - sharing libraries brings you few
benefits at noticeably costs.

But you can happily use shared libraries if you want.  I would be very
surprised to hear of a cpu architecture that works with ucLinux, yet
does not support PIC - and even more surprised to hear of a compiler
where the cpu supports PIC but the compiler does not.  Certainly gcc
will fully support PIC on any ucLinux system, and other compilers are
rarely used on such systems.


Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

Not uClinux itself, but the gcc for some architectures just doesn't
support it.

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load 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?


Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

Of course. Same mostly use "Flat" binaries. (AFAIK, you can do linked
libraries with flat binaries, but I don't have an example).

Quoted text here. Click to load it

NIOS2

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

The final linking is done by the link-loader when you start a program or
load a shared library into memory, so with ucLinux's flat binaries you
don't need PIC to run software or to use shared libraries.  You will
need PID if the shared library has to keep track of application-specific
data, however.

Where PIC is important is for XIP binaries - execute in place - which
run from flash.  These are not loaded into ram, and thus the link-loader
can't patch in addresses.

Quoted text here. Click to load it

Fair enough.  The Nios2 gcc port is out-of-tree, and won't support
features that Altera don't see as important, making it a little more
limited than mainline targets.  But I accept your point here.


Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it


Ah, I now do see your point. This would mean dynamic linking but not
shared object-code. I did not suppose that this is possible (as other
than to void the license-issue discussed there is no big practical
reason to do this.)

Quoted text here. Click to load it

OTOH I suppose that this Arch will get quite low interest, as now the
new NIOS2 can have an MMU and the full Linux port is available
(commercially supported by WindRiver, the community distribution close
to usability.)

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

Yes, you /do/ get shared object code in this way.  Suppose you have a
library libfoo.so that contains a function "bar".  The library's header
contains a record indicating the offset of the function "bar" inside its
object code section.  When the link-loader loads libfoo.so somewhere in
memory, it can then calculate the absolute address of "bar".  Suppose
you then have a program "test" that calls "bar" at some point.  Within
the object code section of "test", the address of "bar" is simply a
placeholder (typically 0), and the header of the "test" file contains a
link table with a record saying "bar" and the offset of the placeholder
within the object code.  When the link-loader loads "test", it copies
the object code section into memory.  It then runs through the link
table from the file's header, and patches in the absolute address of
"bar" (within the in-memory shared library) into the copy of test's
object code.  That's why programs are loaded by a "link-loader", not
just a "loader" - the final stage of linking is carried out at load time.

When you see how this process works, it's easy to see that a second
program can use the same in-memory copy of the shared library in the
same way.

Quoted text here. Click to load it

True enough.  And while the MMU adds some overhead (both in space and
speed for the NIOS2), it is almost certainly worth it if you get to run
full Linux rather than ucLinux.

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

I see. rather complicated but workable.

Quoted text here. Click to load it

That is what I am going to do :)

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

It's not that complicated, really, and it's the way modern Linux systems
work (not just ucLinux).  The alternative to load-time relocation
patching of some sort is to have extra layers of indirection in all
shared library calls, or to use something like software interrupts.

Quoted text here. Click to load it


Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

This isn't quite how it works for normal ELF executables on Linux.  The details
are architecture dependent, but on x86, calls among shared libraries and
executables indirect through a PLT (procedure linkage table).

There is a .plt section containing little stub routines for every function that
is dynamically resolved.  The first time such a stub is called, it branches to
a function which computes the reference, and patches the stub.

The executable code of shared libraries and executables is mapped shared and
read-only (when not under a debugger).


Here is an example, from an actual executable:

Disassembly of section .plt:
...
 8048418:       ff 25 f0 98 04 08       jmp    *0x80498f0
 804841e:       68 00 00 00 00          push   $0x0
 8048423:       e9 e0 ff ff ff          jmp    8048408 <_init+0x18>

The address 0x80498f0 is in another section which is called .got.plt.

The contents of *80498f0 are 804841e! I.e. it just points one instruction down.

So initially, when the program calls getchar, this stub jumps through the entry
in the .got.plt, which brings it right back. It pushes $0x0 on the stack ($0x0
is the offset of the function in the PLT) and calls a routine which will
resolve the symbol and patch the table to go to the right location.

We can see this live:

    $ gdb ./a.out
    [ ... GDB messages ... ]
    (gdb) b main
    Breakpoint 1 at 0x8048556
    (gdb) b getchar
    Function "getchar" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y

    Breakpoint 2 (getchar) pending.
    (gdb) r 0
    Starting program: /home/kaz/a.out 0
    (no debugging symbols found)
    (no debugging symbols found)
    Breakpoint 3 at 0x2adc86
    Pending breakpoint "getchar" resolved

Breakpoint 1, 0x08048556 in main ()
(gdb) p *(void **) 0x80498f0
$1 = (void *) 0x804841e

At this point, getchar has not been called yet, and so the PLT entry still
points to the next instruction in the stub. Now we hit the breakpoint in
getchar:

    (gdb) c
    Continuing.

    Breakpoint 3, 0x002adc86 in getchar () from /lib/tls/libc.so.6
    (gdb) p *(void **) 0x80498f0
    $2 = (void *) 0x2adc80
    (gdb) p getchar
    $3 = {<text variable, no debug info>} 0x2adc80 <getchar>

This time when we print the contents of that PLT location, it points to the
actual address of getchar. The call has been lazily resolved, but still goes
through the indirect jump.

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

IMHO the even more interesting way is to use a file system in DRAM and
when booting load it from a (serial) flash. Here XIP is executing as
fast as "normal" and loading is much faster.

-Michael

Re: Static linking in LGPL, Upgrading LGPL libs
Quoted text here. Click to load it

Yes, that's another use of XIP.  And even though you can write to RAM,
the link-loader can't start writing address patches to the file on the
"disk".

Re: Static linking in LGPL, Upgrading LGPL libs

Quoted text here. Click to load it

Yep. Updates would be done writing into the flash and be activated with
the next boot.

I'll even provide a dual flash image (with CRC check) and have the boot
process load a default one if the CRC fails on the current, thus
upgrading via line is quite safe.

-Michael

Site Timeline