Linux Standard Base Specification for the PPC32 Architecture 1.2

Table of Contents
I. Introduction
1. Introduction
Related Standards
Relevant Libraries
How to Use this Standard
II. Low Level System Information
2. Machine Interface
Processor Architecture
Data Representation
3. Function Calling Sequence
CPU Registers
Floating Point Registers
Stack Frame
Return Values
4. Operating System Interface
Processor Execution Mode
Exception Interface
Signal Delivery
5. Process Initialization
Special Registers
Process Stack (on entry)
Auxiliary Vector
6. Coding Examples
Code Model Overview/Architecture Constraints
Position-Independent Function Prologue
Data Objects
Function Calls
7. C Stack Frame
Variable Argument List
Dynamic Allocation of Stack Space
8. Debug Information
III. Object Format
9. ELF Header
Machine Information
10. Sections
Special Sections
Linux Special Sections
Section Types
Section Attribute Flags
Special Section Types
11. Symbol Table
12. Relocation
Relocation Types
IV. Program Loading and Dynamic Linking
13. Program Header
14. Program Loading
15. Dynamic Linking
Program Interpreter/Dynamic Linker
Dynamic Section
Global Offset Table
Shared Object Dependencies
Function Addresses
Procedure Linkage Table
Initialization and Termination Functions
V. Base Libraries
16. Libraries
Interfaces for libc
Data Definitions for libc
Interfaces for libm
Data Definitions for libm
Interfaces for libpthread
Data Definitions for libpthread
Interfaces for libdl
Data Definitions for libdl
Interfaces for libcrypt
Data Definitions for libcrypt
VI. Execution Environment
17. The /proc Subtree
A. Alphabetical Listing of Interfaces
B. GNU Free Documentation License
How to use this License for your documents
List of Tables
1-1. Related Standards
1-2. Standard Library Names
2-1. Scalar Types
5-1. Extra Auxiliary Types
10-1. ELF Special Sections
10-2. Additional Special Sections
16-1. libc Definition
16-2. libc - RPC Function Interfaces
16-3. libc - System Calls Function Interfaces
16-4. libc - Standard I/O Function Interfaces
16-5. libc - Standard I/O Data Interfaces
16-6. libc - Signal Handling Function Interfaces
16-7. libc - Signal Handling Data Interfaces
16-8. libc - Standard Library Function Interfaces
16-9. libc - Standard Library Data Interfaces
16-10. libc - Localization Functions Function Interfaces
16-11. libc - Localization Functions Data Interfaces
16-12. libc - Socket Interface Function Interfaces
16-13. libc - Wide Characters Function Interfaces
16-14. libc - String Functions Function Interfaces
16-15. libc - IPC Functions Function Interfaces
16-16. libc - Regular Expressions Function Interfaces
16-17. libc - Regular Expressions Data Interfaces
16-18. libc - Character Type Functions Function Interfaces
16-19. libc - Character Type Functions Data Interfaces
16-20. libc - Time Manipulation Function Interfaces
16-21. libc - Time Manipulation Data Interfaces
16-22. libc - Terminal Interface Functions Function Interfaces
16-23. libc - System Database Interface Function Interfaces
16-24. libc - Language Support Function Interfaces
16-25. libc - Large File Support Function Interfaces
16-26. libm Definition
16-27. libm - Math Function Interfaces
16-28. libm - Math Data Interfaces
16-29. libpthread Definition
16-30. libpthread - Posix Threads Function Interfaces
16-31. libdl Definition
16-32. libcrypt Definition
List of Figures
5-1. Initial Process Stack

Chapter 1. Introduction


The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.

The LSB is composed of two basic parts: A common part of the specification describes those parts of the interface that remain constant across all hardware implementations of the LSB, and an architecture-specific part of the specification describes the parts of the specification that are specific to a particular processor architecture. Together, the generic LSB and the architecture-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.

This document is the architecture-specific supplement. It must be used in conjunction with the generic LSB. This document provides architecture-specific information that supplements the generic LSB as well as additional information that is not found in the generic LSB.

This document should be used in conjunction with the documents it references. This document enumerates the system components it includes, but descriptions of those components may be included entirely or partly in this document, partly in other documents, or entirely in other reference documents. For example, the section that describes system service routines includes a list of the system routines supported in this interface, formal declarations of the data structures they use that are visible to applications, and a pointer to the underlying referenced specification for information about the syntax and semantics of each call. Only those routines not described in standards referenced by this document, or extensions to those standards, are described in the detail. Information referenced in this way is as much a part of this document as is the information explicitly included here.

Related Standards

The specifications listed below are referenced in whole or in part by the Linux Standard Base. Such references may be normative or non-normative; a reference to specification shall only be considered normative if it is explicitly cited as such. The LSB may make normative references to a portion of these specifications (that is, to define a specific function or group of functions); in such cases, only the explicitly referenced portion of the specification is to be considered normative.

Table 1-1. Related Standards

System V Application Binary Interface - DRAFT - 22 June 2000
Filesystem Hierarchy Standard (FHS) 2.2
IEEE Standard for Binary Floating-Point Arithmetic
System V Application Binary Interface, Edition 4.1
ISO/IEC 9899: 1990, Programming Languages --C
ISO/IEC 9899: 1999, Programming Languages --C
Linux Assigned Names And Numbers Authority
Large File Support
LI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4
Linux Standard Base
OpenGL® Application Binary Interface for Linux
IEEE Std POSIX 1003.2-1992 (ISO/IEC 9945-2:1993)
System V Application Binary Interface PowerPC Processor Supplement
The PowerPC ™ Architecture: A Specification for a new family of RISC processors
The PowerPC Architecture Book I changes
The PowerPC Architecture Book II changes
The PowerPC Architecture Book III changes
POSIX 1003.1c
CAE Specification, May 1996, X/Open Curses, Issue 4, Version 2 (ISBN: 1-85912-171-3, C610), plus Corrigendum U018
CAE Specification, January 1997, System Interface Definitions (XBD), Issue 5 (ISBN: 1-85912-186-1, C605)
CAE Specification, January 1997, Commands and Utilities (XCU), Issue 5 (ISBN: 1-85912-191-8, C604)
CAE Specification, February 1997, Networking Services (XNS), Issue 5 (ISBN: 1-85912-165-9, C523)
CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)
The Single UNIX® Specification(SUS) Version 1 (UNIX 95) System Interfaces & Headers
System V Interface Definition, Issue 3 (ISBN 0201566524)
System V Interface Definition,Fourth Edition
Double Buffer Extension Library
X Display Power Management Signaling (DPMS) Extension, Library Specification
X Record Extension Library
Security Extension Specification, Version 7.1
X Nonrectangular Window Shape Extension Library Version 1.0
MIT-SHM--The MIT Shared Memory Extension
X Synchronization Extension Library
XTEST Extension Library
X11R6.4 X Inter-Client Exchange (ICE) Protocol
X11R6.4 X11 Input Extension Library
X11R6.4 Xlib - C library
X/Open Portability Guide, Issue 4
X11R6.4 X Session Management Library
X11R6.4 X Toolkit Intrinsics
zlib 1.1.3 Manual



The common part of the LSB Specification that describes those parts of the interface that remain constant across all hardware implementations of the LSB.


The architectural part of the LSB Specification which describes the specific parts of the interface that are platform specific. The archLSB is complementary to the gLSB.

LSB Implementation Conformance

An implementation satisfying the following requirements:

  1. The implementation shall implement fully the architecture described in the hardware manual for the target processor architecture.

  2. The implementation shall be capable of executing compiled applications having the format and using the system interfaces described in this document.

  3. The implementation shall provide libraries containing the interfaces specified by this document, and shall provide a dynamic linking mechanism that allows these interfaces to be attached to applications at runtime. All the interfaces shall behave as specified in this document.

  4. The map of virtual memory provided by the implementation shall conform to the requirements of this document.

  5. The implementation's low-level behavior with respect to function call linkage, system traps, signals, and other such activities shall conform to the formats described in this document.

  6. The implementation shall provide all of the mandatory interfaces in their entirety.

  7. The implementation may provide one or more of the optional interfaces. Each optional interface that is provided shall be provided in its entirety. The product documentation shall state which optional interfaces are provided.

  8. The implementation shall provide all files and utilities specified as part of this document in the format defined here and in other referenced documents. All commands and utilities shall behave as required by this document. The implementation shall also provide all mandatory components of an application's runtime environment that are included or referenced in this document.

  9. The implementation, when provided with standard data formats and values at a named interface, shall provide the behavior defined for those values and data formats at that interface. However, a conforming implementation may consist of components which are separately packaged and/or sold. For example, a vendor of a conforming implementation might sell the hardware, operating system, and windowing system as separately packaged items.

  10. The implementation may provide additional interfaces with different names. It may also provide additional behavior corresponding to data values outside the standard ranges, for standard named interfaces.

LSB Application Conformance

An application with the following characteristics:

  1. Its executable files are either shell scripts or object files in the format defined for the Object File Format system interface.

  2. Its object files participate in dynamic linking as defined in the Program Loading and Linking System interface.

  3. It employs only the instructions, traps, and other low-level facilities defined in the Low-Level System interface as being for use by applications.

  4. If it requires any optional interface defined in this document in order to be installed or to execute successfully, the requirement for that optional interface is stated in the application's documentation.

  5. It does not use any interface or data format that is not required to be provided by a conforming implementation, unless:

  6. It must not use any values for a named interface that are reserved for vendor extensions.

A strictly conforming application does not require or use any interface, facility, or implementation-defined extension that is not defined in this document in order to be installed or to execute successfully.


An LSB conforming application is expected to have no dependencies on any vendor extensions to this document. The most common such extensions are additional function entry points and additional libraries other than the ones defined in this document. If an application requires such extensions, it is not portable, since other LSB conforming implementations may not provide those extensions.

An LSB conforming application is required to use system services on the implementation on which it is running, rather than importing system routines from some other implementation. Thus, it must link dynamically to any routines in the implementation that perform system traps to kernel services.

It is to be expected that some applications may be companion applications to other applications. For example, a query application may be a companion to a database application; a preprocessor may be an adjunct to one or more compilers; a data reformatter may convert data from one document manager to another. In such cases, the application may or may not be LSB conforming, regardless of whether the other application on which it is dependent is LSB conforming. If such an application merely uses data produced by another application, the application's compliance is independent of the other application's compliance. If such an application actually invokes another application during execution (as, for example, a third-party math library), the invoking application is LSB conforming only if it also constitutes a LSB conforming application in combination with the invoked application.

Shell Script

A file that is read by an interpreter (e.g., awk). The first line of the shell script includes a reference to its interpreter binary.



Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.


Describes a value or behavior that is not defined by this document but is selected by an implementor. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior cannot be assured to be portable across conforming implementations. The implementor shall document such a value or behavior so that it can be used correctly by an application.

Same as implementation-dependent.


Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations.

To avoid ambiguity, the opposite of may is expressed as need not, instead of may not.


Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.


Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.


For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations.

For an application, describes a feature or behavior that is recommended programming practice for optimum portability.


Describes the nature of a value or behavior not defined by this document which results from use of an invalid program construct or invalid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.


Describes the nature of a value or behavior not specified by this document which results from use of a valid program construct or valid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.


Same meaning as shall; shall is the preferred term.

Chapter 2. Machine Interface

Processor Architecture

The PowerPC Architecture is specified by the following documents:

Only the features of the PowerPC processor instruction set may be assumed to be present. An application must check /proc/cpuinfo to determine if any additional instruction set features are available before using those additional features. If a feature is not present, then the application may not use it.

An implementation must support the 32-bit computation mode as described in The PowerPC ™ Architecture: A Specification for a new family of RISC processors. Conforming applications shall not use instructions provided only for the 64-bit mode.

Applications conforming to this specification must provide feedback to the user if a feature that is required for correct execution of the application is not present. Applications conforming to this specification should attempt to execute in a diminished capacity if a required feature is not present.

This specification does not provide any performance guarantees of a conforming system. A system conforming to this specification may be implemented in either hardware or software.

Chapter 5. Process Initialization

LSB-conforming applications shall use the Operating System Interfaces as defined in Chapter 3 of the System V Application Binary Interface PowerPC Processor Supplement.

Special Registers

Contrary to what is stated in the Registers part of Chapter 3 of the System V Application Binary Interface PowerPC Processor Supplement there are no values set in registers r3, r4, r5, r6 and r7. Instead the values specified to appear in all of those registers except r7 are placed on the stack. The value to be placed into register r7, the termination function pointer is not passed to the process.

III. Object Format

LSB-conforming implementations shall support an object file , called Executable and Linking Format (ELF) as defined by the System V Application Binary Interface PowerPC Processor Supplement and as supplemented by the Linux Standard Base Specification and this document. LSB-conforming implementations need not support tags related functionality. LSB-conforming applications must not rely on tags related functionality.

Table of Contents
9. ELF Header
10. Sections
11. Symbol Table
12. Relocation

Chapter 10. Sections

Chapter 16. Libraries

An LSB-conforming implementation shall support base libraries which provide interfaces for accessing the operating system, processor and other hardware in the system.

Only those interfaces that are unique to the PowerPC 32 platform are defined here. This section should be used in conjunction with the corresponding section in the Linux Standard Base Specification.

Interfaces for libc

The behavior of the interfaces in this library is specified by the following standards.

ISO/IEC 9899: 1999, Programming Languages --C[1]
Large File Support[2]
LI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4[3]
Linux Standard Base[4]
IEEE Std POSIX.1-1996 [ISO/IEC 9945-1:1996][5]
CAE Specification, February 1997, Networking Services (XNS), Issue 5 (ISBN: 1-85912-165-9, C523)[6]
CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)[7]
System V Interface Definition, Issue 3 (ISBN 0201566524)[8]
System V Interface Definition,Fourth Edition[9]

System Calls

Table 16-3. libc - System Calls Function Interfaces


Standard I/O

Table 16-4. libc - Standard I/O Function Interfaces


Standard Library

Table 16-8. libc - Standard Library Function Interfaces


Wide Characters

Table 16-13. libc - Wide Characters Function Interfaces


String Functions

Table 16-14. libc - String Functions Function Interfaces


Data Definitions for libc


#define EDEADLK	35
#define ENOLCK	37
#define ENOSYS	38
#define ENOTEMPTY	39
#define ELOOP	40
#define ENOMSG	42
#define EIDRM	43
#define ECHRNG	44
#define EL2NSYNC	45
#define EL3HLT	46
#define EL3RST	47
#define ELNRNG	48
#define EUNATCH	49
#define ENOANO	55
#define EBADRQC	56
#define EBADSLT	57
#define EDEADLOCK	58
#define EBFONT	59
#define ENOSTR	60
#define ENODATA	61
#define ETIME	62
#define ENOSR	63
#define ENONET	64
#define ENOPKG	65
#define EREMOTE	66
#define ENOLINK	67
#define EADV	68
#define ESRMNT	69
#define ECOMM	70
#define EPROTO	71
#define EMULTIHOP	72
#define EDOTDOT	73
#define EBADMSG	74
#define EOVERFLOW	75
#define ENOTUNIQ	76
#define EBADFD	77
#define EREMCHG	78
#define ELIBACC	79
#define ELIBBAD	80
#define ELIBSCN	81
#define ELIBMAX	82
#define ELIBEXEC	83
#define EILSEQ	84
#define ERESTART	85
#define ESTRPIPE	86
#define EUSERS	87
#define ENOTSOCK	88
#define EMSGSIZE	90
#define EPROTOTYPE	91
#define ENOPROTOOPT	92
#define EOPNOTSUPP	95
#define EADDRINUSE	98




#define SIGUSR1	10
#define SIGUSR2	12
#define SIGSTKFLT	16
#define SIGCHLD	17
#define SIGCONT	18
#define SIGSTOP	19
#define SIGTSTP	20
#define SIGTTIN	21
#define SIGTTOU	22
#define SIGURG	23
#define SIGXCPU	24
#define SIGXFSZ	25
#define SIGVTALRM	26
#define SIGPROF	27
#define SIGWINCH	28
#define SIGIO	29
#define SIGPWR	30
#define SIGSYS	31
#define SIGUNUSED	31
#define SIGBUS	7

struct sigcontext;


#define TIOCNOTTY	0x5422
#define FIONREAD	1074030207


#define MCL_FUTURE	16384
#define MCL_CURRENT	8192


#define TAB1	1024
#define CR3	12288
#define CRDLY	12288
#define FF1	16384
#define FFDLY	16384
#define XCASE	16384
#define ONLCR	2
#define TAB2	2048
#define TAB3	3072
#define TABDLY	3072
#define BS1	32768
#define BSDLY	32768
#define OLCUC	4
#define CR1	4096
#define IUCLC	4096
#define VT1	65536
#define VTDLY	65536
#define NLDLY	768
#define CR2	8192

#define VWERASE	10
#define VREPRINT	11
#define VSUSP	12
#define VSTART	13
#define VSTOP	14
#define VDISCARD	16
#define VMIN	5
#define VEOL	6
#define VEOL2	8
#define VSWTC	9

#define IXOFF	1024
#define IXON	512

#define CSTOPB	1024
#define HUPCL	16384
#define CREAD	2048
#define CS6	256
#define CLOCAL	32768
#define PARENB	4096
#define CS7	512
#define VTIME	7
#define CS8	768
#define CSIZE	768
#define PARODD	8192

#define NOFLSH	-2147483648
#define ECHOKE	1
#define IEXTEN	1024
#define ISIG	128
#define ECHONL	16
#define ECHOE	2
#define ICANON	256
#define ECHOPRT	32
#define ECHOK	4
#define TOSTOP	4194304
#define PENDIN	536870912
#define ECHOCTL	64
#define FLUSHO	8388608


#define NGREG	48

Interfaces for libm

The behavior of the interfaces in this library is specified by the following standards.

ISO/IEC 9899: 1999, Programming Languages --C[10]
CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)[11]


Table 16-27. libm - Math Function Interfaces


Interfaces for libpthread

The behavior of the interfaces in this library is specified by the following standards.

Linux Standard Base[12]
CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)[13]

Posix Threads

Table 16-30. libpthread - Posix Threads Function Interfaces


Data Definitions for libpthread


#define SIGUSR1	10
#define SIGUSR2	12
#define SIGSTKFLT	16
#define SIGCHLD	17
#define SIGCONT	18
#define SIGSTOP	19
#define SIGTSTP	20
#define SIGTTIN	21
#define SIGTTOU	22
#define SIGURG	23
#define SIGXCPU	24
#define SIGXFSZ	25
#define SIGVTALRM	26
#define SIGPROF	27
#define SIGWINCH	28
#define SIGIO	29
#define SIGPWR	30
#define SIGSYS	31
#define SIGUNUSED	31
#define SIGBUS	7

struct sigcontext;

Appendix A. Alphabetical Listing of Interfaces

Appendix B. GNU Free Documentation License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.


If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.


You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.


The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.



ISO/IEC 9899: 1999, Programming Languages --C


Large File Support


LI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4


Linux Standard Base


IEEE Std POSIX.1-1996 [ISO/IEC 9945-1:1996]


CAE Specification, February 1997, Networking Services (XNS), Issue 5 (ISBN: 1-85912-165-9, C523)


CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)


System V Interface Definition, Issue 3 (ISBN 0201566524)


System V Interface Definition,Fourth Edition


ISO/IEC 9899: 1999, Programming Languages --C


CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)


Linux Standard Base


CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)