Linux Development Platform Specification

[Wojciech "Sas" Cieciwa]

Znalezione na sieci.
Mozecie sie z tym zapoznac ??

Moze jest sens przystosowac do tego PLD ?

Pozdrawiam.
					Sas.
-- 
{Wojciech 'Sas' Cieciwa}  {Member of PLD Team                               }
{e-mail: cieciwa w alpha.zarz.agh.edu.pl, http://www2.zarz.agh.edu.pl/~cieciwa}
{Certified Linux administrator,  http://www.brainbench.com ID=157794        }
-------------- następna część ---------
1              Linux Development Platform Specification, July 2000
2 
3                      DRAFT PROPOSAL --- VERSION 1.0-beta
4 
5 Introduction
6 
7 This is version 1.0-beta of the Linux Development Platform Specification.
8 This specification is designed so that programs developed on a conforming
9 platform are expected to be portable to all generally available Linux
10 distributions as of July 22, 2000. We recommend that all independent
11 software developers create binary versions of their applications using
12 distributions conforming to this specification.
13 
14 In other words, this specification isn't intended to be a standard which
15 tells distributions what to do. Rather, it's a recommendation to third-party
16 developers about how they can create binaries that are likeliest to be
17 portable.
18 
19 A companion committee (the Linux Standard Base) under the Free Standards
20 Group is developing a complete standard for cross-distribution development
21 of applications that will supersede this interim specification. If the
22 superseding specification is not available by December 31, 2000, this
23 specification will be updated by that date.
24 
25 Development platform specification
26 
27 A conforming Linux Development Platform must contain the following packages:
28 
29    * Linux kernel 2.2.x (x >= 14, use latest if possible)
30      ftp://ftp.kernel.org/pub/linux/kernel/v2.2/
31 
32    * glibc 2.1.x (2 <= x <= 3)
33      ftp://ftp.gnu.org/pub/gnu/glibc/
34 
35      Note: glibc 2.1.1 has problems with AIO. Use glibc 2.1.3 if possible or
36      at least glibc 2.1.2.
37 
38    * XFree86 3.3.x (x >= 6)
39      ftp://ftp.xfree86.org/pub/XFree86/3.3.6/
40 
41    * ncurses 4 or 5
42      ftp://ftp.gnu.org/pub/gnu/ncurses/
43 
44      Warning: there is currently a lack of information about how to achieve
45      the highest level of portability when using ncurses.
46 
47    * gcc version egcs-2.91 or gcc-2.95
48      ftp://ftp.gnu.org/pub/gnu/gcc/
49 
50      Note: it is expected that later revisions of gcc will continue to
51      generate binaries (for C only, not C++) that will run on current
52      distributions. We will update the gcc specification as new revisions
53      become available, especially if existing problems are addressed. At
54      this time, we do not recommend using gcc 2.x where x > 95 except to fix
55      critical bugs.
56 
57    * binutils 2.9.x.y (x >= 1)
58      ftp://ftp.valinux.com/pub/support/hjl/binutils/
59 
60      Note: it is expected that later revisions of binutils will continue to
61      generate binaries (for C only, not C++) that will run on current
62      distributions. We will update the binutils specification as new
63      revisions become available, especially if existing problems are
64      addressed. At this time, we do not recommend using binutils 2.w.x.y
65      where w > 9 except to fix critical bugs.
66 
67      These versions of binutils have limitations especially when it comes to
68      correct handling of C++ (support for hidden and protected symbols is
69      missing).
70 
71   ------------------------------------------------------------------------
72 
73 Portability guidelines
74 
75 glibc and X11 libraries
76 
77 We recommend that applications use library versions that are currently
78 available on all distributions conforming to the specification. See above.
79 
80 We recommend that applications be dynamically linked against the glibc and
81 X11 sets of libraries (there are also licensing requirements in the LGPL
82 that must be followed, see below). Linking applications statically will
83 permanently link C library bugs into the application, waste memory and disk
84 space, and (especially in the case of glibc) may cause portability problems
85 on systems with a different kernel revision.
86 
87 Note that if you distribute statically linked binaries, you will also need
88 to provide dynamically linked binaries in order to meet the terms of the
89 licenses on many of these libraries. The dynamic version should be linked
90 against the exact matching library set to the static one.
91 
92 The use of libXaw (distributed as part of X11) is not recommended, but it is
93 part of this specification.
94 
95 POSIX threads
96 
97 The current implementation of threads under Linux do not completely conform
98 to the POSIX threads (POSIX.1c) specification. Because of the immaturity of
99 Linux threads implementation (the kernel is missing support, not the threads
100 library), we do not recommend depending on behavior that diverges from the
101 POSIX standard. There are no guarantees that the behavior will not change
102 because the future behavior may become more compliant with the POSIX threads
103 specification.
104 
105 Therefore, we recommend avoiding using the features of the Linux threads
106 implementation which do not conform to the POSIX specification. Whenever
107 this is not possible, programs should be written with the correct semantics
108 in mind and with a temporary work-around (which ideally can be enabled and
109 disabled dynamically).
110 
111 C++
112 
113 Because of the immaturity of C++ ABI (for name mangling and other such
114 issues), we do not recommend depending on dynamic C++ libraries provided
115 with the system. It is possible, using existing Linux development tools, to
116 development an application in C++ which links statically with libstdc++ and
117 libgcc, or by providing these shared libraries with the application. These
118 shared libraries should be located in an application-specific directory
119 conforming to the /opt specification in FHS 2.1.
120 
121 ncurses
122 
123 Because of the instability in the ncurses ABI and the lack of a consistent
124 version on existing implementations of Linux, we do not recommend depending
125 on the dynamic ncurses libraries provided with the system. It is possible,
126 using existing Linux development tools, to development an application with
127 ncurses which links statically with ncurses version 4 or version 5, or by
128 providing these shared libraries with the application. These shared
129 libraries should be located in an application-specific directory conforming
130 to the /opt specification in FHS 2.1.
131 
132 Security
133 
134 Neither the X11 nor the ncurses library sets can be assumed safe to use in a
135 setuid application.
136 
137 Kernel
138 
139 Many vendors ship 2.2 kernels extended with some 2.4 features. By using
140 these extensions applications may become tied to a vendor kernel or 2.4
141 releases. Therefore third-party developers should only use these features if
142 they actually need them.
143 
144 The following are found in some vendor distribution sets, but are not
145 standard features:
146 
147    * support for 64-bit file sizes on 32-bit platforms
148    * support for direct DMA from and to userspace (kiobufs)
149    * PCMCIA services
150    * support for USB devices
151    * iBCS (SCO, Unixware emulation)
152    * AGP GART management API
153    * extended RAID API (raid 0.90)
154 
155 The following standard kernel features were added after 2.2.14 and should
156 therefore not be used for a portable application:
157 
158    * X.25 socket API MSG_EOR flags
159    * telephony API extensions (PHONE_RING_START taking a CID,
160      PHONE_QUERY_CODEC, PHONE_PSTN_LINETEST, PHONE_VAD)
161    * behavior of readv/writev if fed a vector over 2GB long
162 
163 The one exception to this recommendation (to avoid non-standard kernel
164 features) is for applications that are security-sensitive and require
165 certain standard kernel features that were added after 2.2.14 for security
166 reasons. Any requirements of this type should be documented and a (possibly
167 unsafe) workaround should be added to the application code to provide
168 portability. Here is the list of security-related features of this type:
169 
170    * peer credentials on AF_UNIX sockets
171 
172 Shell scripts
173 
174 Use /bin/sh as the absolute path for all shell scripts. Developers are
175 strongly encouraged to test their shell scripts for correct behavior using
176 the following shells which are used as /bin/sh on most distributions:
177 
178    * bash version 1.14.7
179    * bash version 2.03
180 
181 While bash 1.14.7 does not conform to POSIX in some minor respects, we
182 recommend using only using features present in the POSIX specification and
183 avoiding features specific to bash.
184 
185 To provide the highest level of portability, you may also wish to test
186 applications using either pdksh or ash as /bin/sh because they are sometimes
187 used as /bin/sh on smaller or embedded systems.
188 
189 A small and conservative set of commands should be used in shell scripts in
190 order to maximize portability across Linux distributions. We also recommend
191 using standard POSIX.2 options for each command whenever feasible.
192 
193 FHS 2.1
194 
195 Applications should conform to the Filesystem Hierarchy Standard, version
196 2.1, located at http://www.pathname.com/fhs/.
197 
198 RPM Package Manager
199 
200 If you distribute your application in the RPM format, we recommend
201 distributing RPM version 3 packages, not version 4.
202 
203 Application compatibility testing
204 
205 We recommend that completed applications be tested against at least two
206 different example distributions listed in this document.
207 
208   ------------------------------------------------------------------------
209 
210 Appendix: Example distributions that meet this specification
211 
212    * Caldera OpenLinux 2.4
213    * Conectiva Linux 5.1
214    * Linux-Mandrake 7.0
215    * Red Hat Linux 6.2
216    * SuSE Linux 6.4
217    * TurboLinux 6.0
218    * To be released: Debian GNU/Linux 2.2
219    * To be released: Corel Linux OS Second Edition
220 
221 Note: this is not a comprehensive listing of distributions that meet this
222 specification. This listing is primarily due to availability of
223 distributions on CD-ROM during the writing of this document and subsequent
224 contributions.
225 
226   ------------------------------------------------------------------------
227 
228 Appendix: Frequently Asked Questions
229 
230 What are the trade-offs of building an application with the latest and
231 greatest tools vs. using older versions of the tools?
232 
233 If you build your application with an older set of tools (or on an older
234 release), you will be able to deploy you application to a wider audience.
235 Newer releases of Linux usually support applications that were built on
236 older releases of Linux, but the inverse is not true. An application built
237 on a new release of Linux will possibly not run on an older release of
238 Linux.
239 
240 As an example, assume that there are three releases of Linux, A, B and C,
241 where A is the oldest, and C is the most recent. Because not everyone
242 chooses to upgrade when a new release comes out, the distributions of
243 installed releases at any given time may be 25% A, 50% B, and 25% C. If you
244 build your application on release C, then it may only run on 25% of the
245 installed base. If you build your application on Release B, then it will be
246 able to run on 75% of the installed base.
247 
248 Unfortunately, the answer isn't quite this simple. Because Linux is still
249 maturing, there are some features and interfaces that will only be available
250 on the more recent releases. If your application is dependent on these, then
251 you will have to build on a newer release, and be satisfied with a smaller
252 initial customer base for a while until more people upgrade to newer
253 releases.
254 
255 Why not just specify a POSIX shell?
256 
257 The problem is that just because a shell script runs on a particular "POSIX
258 compliant shell", that doesn't guarantee that it will run everywhere.
259 Remember, this document is directed at application writers, not at
260 distributions. So testing against more than one shell (especially bash 1.x,
261 bash 2.x, and pdksh) is a good portability technique for shell script
262 authors.
263 
264 What's the danger in using glibc 2.2?
265 
266 Applications linked against glibc 2.2 are less likely to run on systems
267 based on glibc 2.1.
268 
269 On the other hand, if application developers build their binaries using a
270 glibc 2.1 system, they are much more likely to have executables that will
271 work on both glibc 2.1 and 2.2 systems.
272 
273 What about Linux kernel 2.4?
274 
275 It has not been released as of the time of this writing, so we don't have
276 complete knowledge about any portability issues related to kernel 2.4. None
277 are expected, but we suggest developing on 2.2 unless 2.4 is a requirement
278 for your application.
279 
280   ------------------------------------------------------------------------
281 
282 Copyright Š 2000 Free Standards Group. All rights reserved.