Static linking in LGPL, Upgrading LGPL libs

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

On Feb 7, 1:35A0%pm, Michael Schnell


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.



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



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

Thx in advans,
Karthik Balaguru

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.



Yes.

DS

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

-Michael

On Feb 7, 2:35A0%pm, Michael Schnell


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

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

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.

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

-Michael

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?

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



NIOS2

-Michael

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.



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.

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.)



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

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.



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.

I see. rather complicated but workable.



That is what I am going to do :)

-Michael

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.

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.

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

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".

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