리눅스도 이젠 표준화의 물결이.....

안녕하세요 리눅스를 좋아하는 서종길입니다.
출처는 아래의 홈피주소가 있어요..

이중요한 사실이... 많이들 올려주세요..

1 Linux Development Platform Specification, October 2000
2
3 VERSION 1.0
4
5 Introduction
6
7 This is version 1.0 of the Linux Development Platform
Specification. This
8 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 October 7, 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.2 or 5
42 ftp://ftp.gnu.org/pub/gnu/ncurses/
43
44 Note: most ncurses applications compile and run under both
ncurses 4.2
45 or 5.0 without any changes, although the ABI has changed
(the release
46 notes for ncurses 5.0 document the reasons for changing the
ABI).
47
48 A few applications must be recompiled when upgrading from
ncurses 4 to
49 5. The affected applications use the low-level terminfo
interface
50 directly via the TERMTYPE struct (which changed in 5.0 to
make it
51 extensible).
52
53 A few applications used the attr_get() function whose
interface as
54 documented by X/Open changed from draft to release. While the
55 getattrs() macro serves the same purpose, the attr_get()
function is
56 documented at part of the X/Open Curses specification.
ncurses 5
57 matches the release version of the X/Open Curses
specification, while
58 ncurses 4 matches the draft specification. (There are a few
other
59 functions which changed in a similar manner, but they are
seldom used:
60 most are in the wide-character support).
61
62 * GCC version egcs-2.91 or GCC 2.95.x (x >= 2)
63 ftp://ftp.gnu.org/pub/gnu/gcc/
64
65 Note: it is expected that later revisions of GCC will
continue to
66 generate binaries (for C only, not C++) that will run on
current
67 distributions. We will update the GCC specification as new
revisions
68 become available, especially if existing problems are
addressed. At
69 this time, we do not recommend using GCC 2.x where x > 95
except to fix
70 critical bugs.
71
72 There are situations where you must use a GCC snapshot such
as GCC 2.96
73 or GCC 2.97, specifically for ia64 and probably sparc64. For
ia32 and
74 alpha, GCC 2.95.x (x >= 2) should be used.
75
76 * binutils 2.9.x.y (x >= 1)
77 ftp://ftp.valinux.com/pub/support/hjl/binutils/
78
79 Note: it is expected that later revisions of binutils will
continue to
80 generate binaries (for C only, not C++) that will run on
current
81 distributions. We will update the binutils specification as
new
82 revisions become available, especially if existing problems
are
83 addressed. At this time, we do not recommend using binutils
2.w.x.y
84 where w > 9 except to fix critical bugs.
85
86 These versions of binutils have limitations especially when
it comes to
87 correct handling of C++ (support for hidden and protected
symbols is
88 missing).
89
90 ----------------------------------------------------------------
--------
91
92 Portability guidelines
93
94 glibc and X11 libraries
95
96 We recommend that applications use library versions that are
currently
97 available on all distributions conforming to the specification.
See above.
98
99 We recommend that applications be dynamically linked against the
glibc and
100 X11 sets of libraries (there are also licensing requirements in
the LGPL
101 that must be followed, see below). Linking applications
statically will
102 permanently link C library bugs into the application, waste
memory and disk
103 space, and (especially in the case of glibc) may cause
portability problems
104 on systems with a different kernel revision.
105
106 Note that if you distribute statically linked binaries, you will
also need
107 to provide dynamically linked binaries in order to meet the
terms of the
108 licenses on many of these libraries. The dynamic version should
be linked
109 against the exact matching library set to the static one.
110
111 The use of libXaw (distributed as part of X11) is not
recommended, but it is
112 part of this specification.
113
114 POSIX threads
115
116 The current implementation of threads under Linux do not
completely conform
117 to the POSIX threads (POSIX.1c) specification. Because of the
immaturity of
118 Linux threads implementation (the kernel is missing support, not
the threads
119 library), we do not recommend depending on behavior that
diverges from the
120 POSIX standard. There are no guarantees that the behavior will
not change
121 because the future behavior may become more compliant with the
POSIX threads
122 specification.
123
124 Therefore, we recommend avoiding using the features of the Linux
threads
125 implementation which do not conform to the POSIX specification.
Whenever
126 this is not possible, programs should be written with the
correct semantics
127 in mind and with a temporary work-around (which ideally can be
enabled and
128 disabled dynamically).
129
130 C++
131
132 Because of the instability of C++ ABI (for name mangling and
other such
133 issues), we do not recommend depending on dynamic C++ libraries
provided
134 with the system. It is possible, using existing development
tools, to
135 develop an application in C++ which links statically with
libstdc++ and
136 libgcc, or by providing these shared libraries with the
application. These
137 shared libraries should be located in an application-specific
directory
138 conforming to the /opt specification in FHS 2.1.
139
140 Note: GCC 3.0 is expected to introduce a new ABI that will be
more stable.
141 We hope to be able to update this specification to include GCC
3.0 when it
142 is supported by most Linux distributions.
143
144 ncurses
145
146 We recommend that new development be done with ncurses 5.
However, there are
147 existing applications linked against ncurses 4.2, which may
require minor
148 changes to work with ncurses 5. These applications use the
shared library
149 versioning, and should work properly if the ncurses 4.2 shared
libraries are
150 installed, e.g., as /lib/libncurses.so.4.2, separate from the
151 libncurses.so.5.0 or other ncurses 5 shared library versions.
152
153 Security
154
155 Neither the X11 nor the ncurses library sets can be assumed safe
to use in a
156 setuid application.
157
158 Kernel
159
160 Many vendors ship 2.2 kernels extended with some 2.4 features.
By using
161 these extensions applications may become tied to a vendor kernel
or 2.4
162 releases. Therefore third-party developers should only use these
features if
163 they actually need them.
164
165 The following are found in some vendor distribution sets, but
are not
166 standard features:
167
168 * support for 64-bit file sizes on 32-bit platforms
169 * support for direct DMA from and to userspace (kiobufs)
170 * PCMCIA services
171 * support for USB devices
172 * iBCS (SCO, Unixware emulation)
173 * AGP GART management API
174 * extended RAID API (raid 0.90)
175
176 The following standard kernel features were added after 2.2.14
and should
177 therefore not be used for a portable application:
178
179 * X.25 socket API MSG_EOR flags
180 * telephony API extensions (PHONE_RING_START taking a CID,
181 PHONE_QUERY_CODEC, PHONE_PSTN_LINETEST, PHONE_VAD)
182 * behavior of readv/writev if fed a vector over 2GB long
183
184 The one exception to this recommendation (to avoid non-standard
kernel
185 features) is for applications that are security-sensitive and
require
186 certain standard kernel features that were added after 2.2.14
for security
187 reasons. Any requirements of this type should be documented and
a safe
188 workaround should be added to the application code to provide
portability.
189 If there is no safe workaround, the application should refuse to
run. Here
190 is the list of security-related features of this type:
191
192 * peer credentials on AF_UNIX sockets
193
194 Shell scripts
195
196 Use /bin/sh as the absolute path for all shell scripts.
Developers are
197 strongly encouraged to test their shell scripts for correct
behavior using
198 the following shells which are used as /bin/sh on most
distributions:
199
200 * bash version 1.14.7
201 * bash version 2.0x (x >= 3)
202
203 While bash 1.14.7 does not conform to POSIX in some minor
respects, we
204 recommend using only using features present in the POSIX
specification and
205 avoiding features specific to bash.
206
207 To provide the highest level of portability, you may also wish
to test
208 applications using either pdksh or ash as /bin/sh because they
are sometimes
209 used as /bin/sh on smaller or embedded systems.
210
211 A small and conservative set of commands should be used in shell
scripts in
212 order to maximize portability across Linux distributions. We
also recommend
213 using standard POSIX.2 options for each command whenever
feasible.
214
215 FHS 2.1
216
217 Applications should conform to the Filesystem Hierarchy
Standard, version
218 2.1, located at http://www.pathname.com/fhs/.
219
220 RPM Package Manager
221
222 If you distribute your application in the RPM format, we
recommend
223 distributing RPM version 3 packages, not version 4.
224
225 Application compatibility testing
226
227 We recommend that completed applications be tested against at
least two
228 different example distributions listed in this document.
229
230 ---------------------------------------------------------------
---------
231
232 Appendix: Example distributions that meet this specification
233
234 * Caldera OpenLinux 2.4
235 * Conectiva Linux 5.1
236 * Linux-Mandrake 7.0
237 * Red Hat Linux 6.2
238 * SuSE Linux 6.4
239 * TurboLinux 6.0
240 * Debian GNU/Linux 2.2
241 * Corel Linux OS Second Edition
242
243 Note: this is not a comprehensive listing of distributions that
meet this
244 specification. This listing is primarily due to availability of
245 distributions on CD-ROM during the writing of this document and
subsequent
246 contributions.
247
248 ---------------------------------------------------------------
---------
249
250 Appendix: Frequently Asked Questions
251
252 What are the trade-offs of building an application with the
latest and
253 greatest tools vs. using older versions of the tools?
254
255 If you build your application with an older set of tools (or on
an older
256 release), you will be able to deploy you application to a wider
audience.
257 Newer releases of Linux usually support applications that were
built on
258 older releases of Linux, but the inverse is not true. An
application built
259 on a new release of Linux will possibly not run on an older
release of
260 Linux.
261
262 As an example, assume that there are three releases of Linux, A,
B and C,
263 where A is the oldest, and C is the most recent. Because not
everyone
264 chooses to upgrade when a new release comes out, the
distributions of
265 installed releases at any given time may be 25% A, 50% B, and
25% C. If you
266 build your application on release C, then it may only run on 25%
of the
267 installed base. If you build your application on Release B, then
it will be
268 able to run on 75% of the installed base.
269
270 Unfortunately, the answer isn't quite this simple. Because Linux
is still
271 maturing, there are some features and interfaces that will only
be available
272 on the more recent releases. If your application is dependent on
these, then
273 you will have to build on a newer release, and be satisfied with
a smaller
274 initial customer base for a while until more people upgrade to
newer
275 releases.
276
277 Why not just specify a POSIX shell?
278
279 The problem is that just because a shell script runs on a
particular "POSIX
280 compliant shell", that doesn't guarantee that it will run
everywhere.
281 Remember, this document is directed at application writers, not
at
282 distributions. So testing against more than one shell is a good
portability
283 technique for shell script authors.
284
285 What's the danger in using glibc 2.2?
286
287 Applications linked against glibc 2.2 are less likely to run on
systems
288 based on glibc 2.1.
289
290 On the other hand, if application developers build their
binaries using a
291 glibc 2.1 system, they are much more likely to have executables
that will
292 work on both glibc 2.1 and 2.2 systems.
293
294 What about Linux kernel 2.4?
295
296 It has not been released as of the time of this writing, so we
don't have
297 complete knowledge about any portability issues related to
kernel 2.4. None
298 are expected, but we suggest developing on 2.2 unless 2.4 is a
requirement
299 for your application.
300
301 ---------------------------------------------------------------
---------
302
303 Copyright ?2000 Free Standards Group. All rights reserved.