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: Michael Schnell on 8 Feb 2010 16:22 On 08.02.2010 21:49, David Brown wrote: > 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
From: David Brown on 9 Feb 2010 04:48 On 08/02/2010 22:18, Michael Schnell wrote: > On 08.02.2010 21:59, David Brown wrote: >> 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. >> > > I see. rather complicated but workable. > 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. >> 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. > > That is what I am going to do :) > > -Michael
From: Nobody on 9 Feb 2010 05:08 On Mon, 08 Feb 2010 06:01:57 -0800, karthikbalaguru wrote: >> The LGPL was conceived for dynamically linked shared libraries, even >> though it is not exclusively limited to them. Embedded systems were >> simply not considered at the time. > > This is interesting ! > I wonder why it was not revised after the > evolution of embedded systems . Strange ? Not really. If there is a conflict between what's convenient for the developer and what's convenient for the user, expect the FSF to side with the user every time. AIUI, the FSF was born from RMS' frustration with being unable to modify the programs he was using. From his perspective, software which the user cannot modify for their particular needs is substandard and should be replaced with software which can be modified. From that perspective, the only reason to permit developers to use certain (i.e. LGPL'd) libraries in commercial applications is that at least the user can modify that part of the program. If they couldn't even do that (because the library was linked statically and couldn't be replaced), there would be no reason to permit the developer to use the library at all. The ultimate goal is to encourage the development and use of Free Software, meaning software that anyone can modify and share. If this benefits commercial software, that's either coincidence or a means to an end, not a goal.
From: Kaz Kylheku on 10 Feb 2010 20:33 On 2010-02-08, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: > 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. 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: .... 08048418 <getchar(a)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.
From: Karthik Balaguru on 12 Feb 2010 02:45
On Feb 8, 1:49 am, David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > Jon Kirwan wrote: > > On Sun, 7 Feb 2010 08:44:57 -0800 (PST), Karthik Balaguru > > <karthikbalagur...(a)gmail.com> wrote: > > >> <snip> > >> But, i am not sure how LGPL is helpful in scenarios > >> in which static linking is only possible. Any ideas to > >> do static linking without providing source code and > >> in the same time support for LGPL library upgradation ? > >> <snip> > > > I'm also interested in reasoned answers to this question. I > > _write_ library routines, on occasion, which I'd like to make > > available fairly freely -- for no-cost commercial use as well > > as private/personal hobbyist use. In my case, I'm interested > > in licenses to consider and a description of trade-offs that > > I can gather and understand, more than a solution that solves > > the specific LGPL issue, since I can choose as I want what > > license to apply. > > > An example is that I submitted a fast, LGPL licensed, > > floating point division routine for the 8051 core facet of > > SDCC. (I've no idea how to actually get it included in the > > distribution others may see, so that is yet another thing to > > learn about.) However, I hadn't bothered to go read the > > license in detail, reading instead a web page with its own > > discussion recommending it for situations that _sounded_ to > > me similar to what I wanted, and later uncovered the fact > > talked about here. I'd like to change it now, but don't know > > what fits my interest better. Rather than licensing it 6 > > ways to Sunday before finally figuring out which fits better > > someday, I wouldn't mind an education first so that I can > > make one more license update that is a reasoned one. > > > I've looked at some of the BSD licenses, the wiki page on > > free licenses, Apple's APSL, the Apache licenses, and a bevy > > of other "suggestions" but still haven't decided how to weigh > > the choices well or what they emphasize. Many of these are > > targeted at very specific "desires" that aren't so much my > > own concerns. I'm not even entirely sure what concerns > > _should_ be my concerns, though I can think of a few. > > > Hire an attorney just to give away source code? Not likely. > > So, I'd enjoy hearing some discussion. > > > Jon > > It's a bad idea to pick a license because it's a common license, and > some rough reading of web pages make it sound okay. There are endless > numbers of libraries (and embedded development examples) that the author > has given out under the GPL "so that others can use it however they want > in their projects". > > When deciding on a license for your code, I would first make an > absolutely clear statement of your intentions. This should be > prominently displayed on the web page hosting your code, and should be > included (or referred to) in each file. The great majority of potential > users are honest and respectful - they will honour your wishes here, and > it's a lot easier to do that when your wishes are in clear English > rather than legalise. > > For those that will knowingly violate your wishes, there are three > categories depending on their country and legal system. > > If the violator is in the USA, you will lose regardless of what license > you have used. Unless your code is "big" enough to get the backing of > the FSF, you simply don't have enough money to win regardless of who is > wrong or right. > > If the violator is in Europe, a clear statement of your wishes will > count heavily in your favour in any small claims court - these are > designed to help "little people" against large companies. > > If the violator is in the far east, you'll never know about it, and have > no way of pursuing the matter even if you do learn of it. > > As for the license itself, I'd recommend a "GPL with exception clause". > Look at FreeRTOS for an example. With such a license, the code /you/ > have written is under the GPL, as are any derivative files. But any > files and modules the user has written are considered independently > licensed. This really gives you the benefits of the GPL while leaving > the user free to include the code in their closed source programs > (statically linked, and without any requirements for the user to be able > to update the software). Any modifications the developer makes to > /your/ code have to be released according to the GPL requirements. > > The Mozilla Public License (MPL), used by Firefox etc., is basically the > same, but with different details regarding things like copyright > notices. But I'd recommend starting off looking at the FreeRTOS example: > > <http://www.freertos.org/index.html?http://www.freertos.org/a00114.html>- Hide quoted text - > > - Show quoted text - 'GPL with exception clause' is interesting. True that without applying the linking exception, code linked with GPL code becomes automatically GPL. Reer - http://en.wikipedia.org/wiki/GPL_linking_exception LGPL's linking exception appears to be more customer friendly. Thx, Karthik Balaguru |