From The Linux Foundation
Contents |
LSB 3.0 Release Notes, Final Edition
The LSB project team is proud to announce LSB Version 3.0. The specification is available for download at [1]. 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 Core specification, described by a Generic specification and seven Architecture Specific supplements. The Core specification in turn is made up of three "books", however these are not released separately, only combined as lsb-core:
- the ELF specification,
- the LSB interface specification,
- the packaging specification
- The C++ module (with Generic module and seven Architecture Specific supplements)
- The Graphics Module
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.
Summary of Major Differences
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.
C++ Module Changes
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.
Core Module Changes
New Library
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.
New Interfaces
The following library interfaces are new in this release:
- libc: duplocale, freelocale, newlocale, uselocale, getgrouplist, posix_openpt, getlogin_r.
- The first four interfaces represent thread-local locale routines, currently unique to glibc and using LSB as the base specification. The remaining interfaces represent missing interfaces from POSIX which were already universally available on implementations.
- libpthread: pthread_attr_getinheritsched, pthread_attr_getschedpolicy, pthread_attr_getscope, pthread_attr_setinheritsched, pthread_attr_setschedpolicy, pthread_attr_setscope, pthread_getschedparam, pthread_setschedparam, pthread_setschedprio.
- These interfaces represent the POSIX Thread Execution Scheduling feature set.
Note that pthread_getschedprio is part of this set to but was not added upstream until GLIBC_2.3.4 - apparently correcting an omission.
- librt (new library): clock_getcpuclockid, clock_getres, clock_gettime, clock_nanosleep, clock_settime, shm_open, shm_unlink, timer_create, timer_delete, timer_getoverrun, timer_gettime, timer_settime.
- These interfaces align with the POSIX Timers and Shared Memory Objects features.
New Symbol Versions
- _sys_siglist uplifted to GLIBC_2.3.3
- nftw, nftw64 uplifted to GLIBC_2.3.3
- regexec uplifted to GLIBC_2.3.4
- ppc64, ppc32: _ _sigsetjmp, _longjmp, _setjmp, longjmp, siglongjmp, getcontext, setcontext, swapcontext were changed to version GLIBC_2.3.4 to match a change to an underlying data structure.
Data Structure Changes
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 (ucontext_t)
contains an 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).
Linker Version
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.
Package Manager
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-core-noarch and lsb-graphics-noarch, as well as two architecture-specific ones, lsb-core-arch and lsb-graphics-arch. These must be providing the value 3.0.
lsb_release
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
neutral ones, core-3.0-noarch and graphics-3.0-noarch,
as well as two architecture-specific ones, core-3.0-arch
and graphics-3.0-arch.
$ lsb_release -v LSB Version: core-3.0-ia64:core-3.0-noarch:graphics-3.0-ia64:graphics-3.0-noarch
Commands
The following required commands have been added in this release:
- Commands: ed, logger, lp, mailx, pax
- Shell builtins: cd, getopts, read, umask, wait
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.
Withdrawn, Deprecated, Changed Interfacess
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:
- Network entries: endnetent, setnetent
- Domain names: getdomainname, setdomainname
- Signals: siggetmask, sigstack, sigblock
- Old regular expression: step, advance, loc1, loc2, locs
- Host/network names: getnetbyaddr, gethostbyname_r
- Administrative: sethostid
- BSD regular expression: re_comp, re_exec
- Strings: strfry, strverscmp
- BSD process wait: wait3
- Tune kernel clock (admin): adjtimex
- Random numbers: random_r
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.
Graphics Module Changes
- Added Xevi extension to libXext.
- Added X input extension - new library libXi
New Library
The libXi library, an interface to the X Input extentsion, is added to the LSB.
New Interfaces
The following library interfaces are new in this release.
- libXext: XeviGetVisualInfo, XeviQueryExtension, XeviQueryVersion
- libXi: XAllowDeviceEvents, XChangeDeviceControl,
- XChangeDeviceDontPropagateList, XChangeDeviceKeyMapping,
- XChangeFeedbackControl, XChangeKeyboardDevice, XChangePointerDevice,
- XCloseDevice, XDeviceBell, XFreeDeviceControl, XFreeDeviceList,
- XFreeDeviceMotionEvents, XFreeDeviceState, XFreeFeedbackList,
- XGetDeviceButtonMapping, XGetDeviceControl, XGetDeviceDontPropagateList,
- XGetDeviceFocus, XGetDeviceKeyMapping, XGetDeviceModifierMapping,
- XGetDeviceMotionEvents, XGetExtensionVersion, XGetFeedbackControl,
- XGetSelectedExtensionEvents, XGrabDevice, XGrabDeviceButton,
- XGrabDeviceKey, XInput_find_display, XListInputDevices, XOpenDevice,
- XQueryDeviceState, XSelectExtensionEvent, XSendExtensionEvent,
- XSetDeviceButtonMapping, XSetDeviceFocus, XSetDeviceMode,
- XSetDeviceModifierMapping, XSetDeviceValuators, XUngrabDevice,
- XUngrabDeviceButton, XUngrabDeviceKey
Compatibility With Previous Versions
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.
Support of This ABI
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 LI18NUX2000-Level1
section of 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.