UClinux Shared Library

From eLinux.org
Revision as of 08:28, 28 October 2011 by Cschalle (Talk | contribs) (Add category)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Using Shared Library on uClinux

Shared Library support is important for various cases. Especially if you are using uClinux with LGPL library, if there is no Shared Library support with your system, that means you get hit by GPL/LGPL license issue because LGPL library can only be linked by Shared Library (dynamic link) or the application source code needs to be provided to the customer (if the customer wants).

There were various efforts for supporting Shared Library on uClinux so far. This page describes those efforts with corresponding information.

Shared FLAT

The Shared FLAT format follows the FLAT format in terms of being an extremely stripped down and lightweight format:

  • minimal file header (~48 bytes)
  • minimal relocation table
  • only sections actually needed at runtime are retained (.text/.data/etc...)

However, these things come by sacrificing flexibility:

  • every shared library has a unique hardcoded ID numbers which must be managed manually
  • maximum of ~256 shared libs
  • no dynamic support (libdl -- dlopen/dlsym/dlclose/etc...)
  • maximum individual executable size of 8megs

FDPIC ELF

The FDPIC ELF format brings all the amenities of the standard ELF format as seen on Desktop Linux systems. The trade offs are mostly obvious:

  • all executable code must be Position Independent Code (PIC)
  • no limits on the number of shared libraries
  • linking and library lookup is natural (SONAMEs, search paths, etc...)
  • dynamic library/plugin support works (libdl -- dlopen/dlsym/dlclose/etc...)

Kernel 2.6.x status

There are two options with recent kernels:

  • Shared FLAT format (grep the kernel for CONFIG_BINFMT_SHARED_FLAT)
  • FDPIC ELF (originally the implemented for FR-V)

Most no-mmu Linux architectures support Shared FLAT, but the FDPIC ELF format is gathering ports. Support will greatly depend on the exact kernel version you are using, so check the fs/Kconfig.binfmt file if you are unsure.

Kernel 2.4.x status

Shared libraries under uClinux mini-HOWTO: http://www.ucdot.org/article.pl?sid=03/11/25/1126257&mode=thread

But ARM does not support it, see at bottom page: http://www.ucdot.org/article.pl?sid=03/07/24/1333235&mode=thread

Another interesting topic: http://www.ucdot.org/article.pl?sid=03/10/21/2153216&mode=thread

Ridge Run and SnapGear announcement

Ridge Run and SnapGear has announced that they implemented Shared Library on uClinux long time ago.

For more information: http://linuxdevices.com/articles/AT3186625227.html

Ridge Run approach uses ELF format file and Snap Gear approach uses FLAT file format.

The FLAT File Format method is supported by all Linux targets that support running Linux without an MMU

Ridge Run stopped their business at 2002 but they are now back. Their method is described at: http://www.ridgerun.com/XflatPages/CadenuxXFLATSharedLibraries

When they stopped, some of their code was released under GPL because they had something to do with Texas Instruments. Monta Vista may have some more information on this but currently none has seen Ridge Run's Shared Library implementation code at the open source region.

But after they are back to their business, the new Ridge Run has set up xflat as an open source project at http://www.xflat.org

m68knommu

The m68knommu architecture uses the FLAT file format for shared libraries.

Shared library support was working in gcc 2.95.3 with older 2.4 kernels from Snapgear.

GCC 3.x does not work with shared libraries.

The Code Sourcery toolchain 4.4-216 is working with linux kernel 2.6.34.

Credit

This rough page was originally created by Shawn Kwon but most of the information were collected from comments of various people including Paul Mundt, Steve Bunch, Tim Bird, Greg Ungerer, Todd Fischer, Alan Carvalho de Assis at celinux-dev mailing list. All the credit should go to them.