The LSB project team is proud to announce LSB Version 3.0. The specification is available for download at . As this is a major release, indicated by a change in the first component of the version number, there is no guarantee of binary compatibility with previous versions. The set of interfaces, the details and symbol versions, and layout of certain data structures may have changed between this release and the previous one. Thus, applications conforming to previous versions of the LSB will require recompilation and/or relinking (see also Compabitility section below).
The LSB consists of a number of components, or modules:
The seven supported architectures for LSB 3 are: IA32, IA64, PPC32, PPC64, S390, S390X, X86_64
There may be other modules or books in an LSB specification development tree but only the above are released as part of LSB 3.0.
In general, LSB 3.0 does not represent a major technological change from LSB 2.0. However, in accordance with the roadmap published in August 2004 when LSB 2.0 was released, LSB 3.0 requires a newer release of the underlying ABI used for C++ support. For most vendors, this means that gcc 3.4 or later (actually, the minimum acceptable level is 3.4.4), or compatible equivalent must be used, and any C++ application built with gcc 3.3 or earlier must be recompiled. In addition, a few deprecated interfaces have been removed, some new commonly used interfaces have been added, a library has been added to the core set, some X11 extensions were added, and some additional commands have been introduced. Most of these changes are to increase compatibility with the POSIX specification, and to address other comments submitted during the IsoBallot.
The C++ ABI is changed to the one used by gcc 3.4 (indications
are that gcc 4.0 is also compatible with this).
As designed by the gcc project, the libstdc++ library has
completely changed symbol versions and the library major version,
to match deployments, LSB needed to make the same change.
This was done intentionally to clearly distinguish the library from
the one used by earlier compiler versions.
libstdc++.so.6 is now
the required library. This library can easily coexist with the
libstdc++.so.5 used to provide LSB 2.x conformance.
During the review period some unneeded symbols were discovered,
and since this new library has no backward compatibility issues in
the context of the LSB, they were simply removed (e.g. istrstream,
ostrstream). The symbol and symbol version set matches that of
GCC 3.4.2 and 3.4.3.
The realtime library librt is restored to the LSB. This library was present in very early versions of the LSB, then removed because a major component of that library, asynchronous I/O support (aio_* and lio_* interfaces), did not meet the LSB criteria. Upon investigation, it became evident that exclusion of the entire library was not necessary, and the library has been restored to the LSB with a subset of the interfaces supported (see below). The aio_*, lio_* and mq_* interfaces found in various versions of librt are excluded from this version of the specification.
The following library interfaces are new in this release:
Note that pthread_getschedprio is part of this set to but was not added upstream until GLIBC_2.3.4 - apparently correcting an omission.
On the Power architectures (ppc32 and ppc64), recent versions
of glibc have expanded the machine context structure (
mcontext_t) to help support some newer processors. Since a user context structure (
mcontext_t and a
__jmp_buf needs to be sized
to save a
ucontext_t, all routines that deal directly with these
data structures have had an incompatible ABI change, and thus new symbol
versions (see above).
Since a major version may include incompatible changes, such as new libraries and new or deleted interfaces in existing libraries, the version number is incremented in the LSB linker name so that the implementation can detect which version of the LSB an application conforms to. The LSB linker version always matches the LSB major version number. The linker name is architecture-specific.
The packaging system on an LSB 3 conforming system must supply four version dependencies which packages may require. There are two architecture neutral ones,
lsb-graphics-noarch, as well as two architecture-specific ones,
lsb-graphics-arch. These must be providing the value 3.0.
The lsb_release command on an LSB 3 conforming system must supply four
version dependencies which may be checked by shell commands (calling
lsb_release -v). There are two architecture
as well as two architecture-specific ones,
$ lsb_release -v LSB Version: core-3.0-ia64:core-3.0-noarch:graphics-3.0-ia64:graphics-3.0-noarch
The following required commands have been added in this release:
These commands are added primarly for POSIX alignment: the LSB command set now matches the base POSIX requirement. The specification has appropriate details on each in the form of any differences from the POSIX specification.
Note lsbinstall was present in preview versions of LSB 3, but is not part of the final specification, except that it appears in an informative (not normative) annex indicating future directions for the LSB.
In accordance with published procedures, a number of interfaces previously marked as deprecated have been removed in this release, and certain interfaces now require a different symbol version. Removal of an interface from the specification or a change to the symbol version, does not require an implementation to remove the interface or previous symbol version from their libraries. Rather, it means that a runtime seeking LSB 3 certification alone need not provide the interface or version. An LSB 3 conforming application must not depend on a withdrawn interface, and will not be able to certify if it uses one. These interfaces were all from the C library:
Applications that use any of the above interfaces will require modification in order to gain certification to LSB 3.
Symbol version changes are detailed in the New Symbol Versions section.
The libXi library, an interface to the X Input extentsion, is added to the LSB.
The following library interfaces are new in this release.
The LSB specification does not require an implementation conforming to a particular LSB version to provide support for other LSB versions as a condition of conformance. Neither does it prohibit multiple-version support, and providing both LSB 2 and LSB 3 support is highly encouraged.
The LSB project does not know of technological reasons why LSB 2 and LSB 3 runtimes cannot easily coexist. It should be possible to support LSB 2 together with LSB 3 from the same set of libraries, except in the case of libstdc++ and librt. There was no librt in LSB 2, and for libstdc++, LSB 3 provides a new library name which does not conflict with that needed for the LSB 2. If version coexistence through the same libraris is not possible for some implementation-speficfic reason, the distinguished lsb linker name (see Linker Version above) provides a "hook" to provide a separate library needed for an older version of the LSB.
MultiVersion describes how an implementation might support multiple versions of the specification simultaneously.
To support packaging, the required package manager provides are versioned, and the description of lsb_release (as well as the current sample implementation) has support for multiple version and module provides.
LSB 1.3 support may also be possible to provide.
There are a small number of known issues where the contents of this specification are not widely deployed.
The main area is a set of multi-byte character handling
requirements that are not fully implemented by upstream
packages, including coreutils, diffutils, grep and cpio.
The issues are exposed in execution of the
lsb-runtime-test. A patch set is available
for all of these issues, however the patches are developed
and maintained by the OpenI18N FSG project and are not officially
authorized by the projects whose packages are affected. Some
of the patches may not be updated for current upstream
package versions as of this writing.
For new command lp, the required functionality is very limited, and there's no requirement to support a full lp printing system. Most printing systems (e.g. cups) seem to already provide an alias named lp. For mailx, the package nail (nail, not mail) is known to be POSIX-conforming; the package mailx commonly ends up installing the binary as Mail and an alias (symlink) named mailx should be sufficient.