From Fedora Project Wiki
(incorporate pjones' feedback)
Line 5: Line 5:
 
'''MUST''': Packages that install static library archives (.a files) must do one of:
 
'''MUST''': Packages that install static library archives (.a files) must do one of:
 
* build them as PIC objects,
 
* build them as PIC objects,
* build both PIC and non-PIC objects, and ensure that consumers of the library use the right one,
+
* build both PIC and non-PIC libraries, with a .pc file for each for dependent packages to use,
 
* document (in the spec file) why the static libraries are not built PIC.
 
* document (in the spec file) why the static libraries are not built PIC.
  
Line 21: Line 21:
  
 
In any case, non-PIC static libraries need explicit approval from FESCO.
 
In any case, non-PIC static libraries need explicit approval from FESCO.
 +
 +
Packages that install non-PIC static libraries should be explicitly listed in the wiki somewhere.
  
 
== Documentation ==
 
== Documentation ==
  
Packages that install non-PIC static libraries should be explicitly listed in the wiki somewhere.
+
Typically all that's needed to build a library PIC is to add -fPIC to CFLAGS.  If a library contains assembly code, adding -fPIC won't make the assembly magically become PIC; code changes will be necessary in this case.
 +
 
 +
Autotools-based projects can usually disable static library creation by configuring with --disable-static, and can force PIC static libraries by configuring with --with-pic.
 +
 
 +
TODO: Add pc file templates for static and static-nonpic.
  
 
== Open Issues ==
 
== Open Issues ==
  
* If the packaging is modified to install both PIC and non-PIC archives, how to name them?  Or is it better to make two (conflicting) subpackages, eg libfoo-static and libfoo-static-nonpic?  That has the advantage that it's easy to track which packages use the non-PIC code, but precludes a package building both an app with the non-PIC code and a library with the PIC code.  Presumably any library in that state should just stop pretending to be a non-shared library though.
 
 
* Add howto info for common build systems to build static libraries PIC.
 
* Add howto info for common build systems to build static libraries PIC.
  
 
[[Category:Packaging guidelines drafts ]]
 
[[Category:Packaging guidelines drafts ]]

Revision as of 20:32, 4 February 2010

Packaging Static Libraries

Summary

MUST: Packages that install static library archives (.a files) must do one of:

  • build them as PIC objects,
  • build both PIC and non-PIC libraries, with a .pc file for each for dependent packages to use,
  • document (in the spec file) why the static libraries are not built PIC.

Rationale

Some architectures (including i386, but not including x86_64) permit non-position-independent code. A static library may, through subsequent linking, be included in any of another static library, an application, or a shared library.

On architectures that permit it, non-PIC code comes with a tradeoff. Since the load address is assumed, the compiler has an additional register to use, which can be a - usually small - performance benefit. However, any otherwise relocatable object (shared library or PIE executable) that the non-PIC code is linked into will require text relocations. Text relocations impose a performance penalty on executable startup, and effectively make the code unshareable, thus negating the benefits of making the code into a shared library in the first place.

In general, it is preferable to err on the side of PIC. Text relocations are incompatible with some of the security measures in Fedora, and the performance benefit of actually being able to share your shared library code in memory outweighs any performance benefit from the additional register. Static libraries in particular should be built PIC, since if not their non-PIC-ness effectively poisons any shared libraries they are included in.

Exceptions

Non-PIE applications may legitimately include non-PIC code with no performance penalty. If a static library is only included in non-PIE applications, it need not be built PIC. This case is expected to be rare, limited mostly to numeric computation libraries like atlas or fftw where performance is critical.

In any case, non-PIC static libraries need explicit approval from FESCO.

Packages that install non-PIC static libraries should be explicitly listed in the wiki somewhere.

Documentation

Typically all that's needed to build a library PIC is to add -fPIC to CFLAGS. If a library contains assembly code, adding -fPIC won't make the assembly magically become PIC; code changes will be necessary in this case.

Autotools-based projects can usually disable static library creation by configuring with --disable-static, and can force PIC static libraries by configuring with --with-pic.

TODO: Add pc file templates for static and static-nonpic.

Open Issues

  • Add howto info for common build systems to build static libraries PIC.