Do you have a question? Post it now! No Registration Necessary
- karthikbalaguru
February 7, 2010, 5:12 am

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

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

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

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

Re: Static linking in LGPL, Upgrading LGPL libs

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

Re: Static linking in LGPL, Upgrading LGPL libs
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

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

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

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

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

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.

Re: Static linking in LGPL, Upgrading LGPL libs

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

Re: Static linking in LGPL, Upgrading LGPL libs

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.

Re: Static linking in LGPL, Upgrading LGPL libs

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.


Re: Static linking in LGPL, Upgrading LGPL libs

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

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
- » Spidev guidance
- — Next thread in » Embedded Linux
-
- » Problem with absolute binary name
- — Previous thread in » Embedded Linux
-
- » Crosscompiling for ARM: reloc type R_ARM_ABS32 is not supported for PIC - ...
- — Newest thread in » Embedded Linux
-
- » White House In Danger Of Imminent Collapse, First Family Evicted
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Using Bats To Burn Down the House
- — The site's Last Updated Thread. Posted in » Electronics Design
-