| Developer GuideChapter 3. Libraries and Runtime SupportRed Hat Enterprise Linux 6 supports the development of custom applications in a wide variety of programming languages using proven, industrial-strength tools. This chapter describes the runtime support libraries provided in Red Hat Enterprise Linux 6. The following table compares the version information for runtime support packages in supported programming languages between Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 5, and Red Hat Enterprise Linux 4. This is not an exhaustive list. Instead, this is a survey of standard language runtimes, and key dependencies for software developed on Red Hat Enterprise Linux 6. Table 3.1. Language and Runtime Library Versions | Package Name | Red Hat Enterprise 6 | Red Hat Enterprise 5 | Red Hat Enterprise 4 |
|---|
| glibc | 2.12 | 2.5 | 2.3 | | libstdc++ | 4.4 | 4.1 | 3.4 | | boost | 1.41 | 1.33 | 1.32 | | java | 1.5 (IBM), 1.6 (IBM, OpenJDK, Oracle Java) | 1.4, 1.5, and 1.6 | 1.4 | | python | 2.6 | 2.4 | 2.3 | | php | 5.3 | 5.1 | 4.3 | | ruby | 1.8 | 1.8 | 1.8 | | httpd | 2.2 | 2.2 | 2.0 | | postgresql | 8.4 | 8.1 | 7.4 | | mysql | 5.1 | 5.0 | 4.1 | | nss | 3.12 | 3.12 | 3.12 | | openssl | 1.0.0 | 0.9.8e | 0.9.7a | | libX11 | 1.3 | 1.0 | | | firefox | 3.6 | 3.6 | 3.6 | | kdebase | 4.3 | 3.5 | 3.3 | | gtk2 | 2.18 | 2.10 | 2.04 |
The compat-glibc RPM is included with Red Hat Enterprise Linux 6, but it is not a runtime package and therefore not required for running anything. It is solely a development package, containing header files and dummy libraries for linking. This allows compiling and linking packages to run in older Red Hat Enterprise Linux versions (using compat-gcc-* against those headers and libraries). Running rpm -qpi compat-glibc-* will provide some information on how to use this package. Compatibility specifies the portability of binary objects and source code across different instances of a computer operating environment. Officially, Red Hat supports current release and two consecutive prior versions. This means that applications built on Red Hat Enterprise Linux 4 and Red Hat Enterprise Linux 5 will continue to run on Red Hat Enterprise Linux 6 as long as they comply with Red Hat guidelines (using the symbols that have been white-listed, for example). Red Hat understands that as an enterprise platform, customers rely on long-term deployment of their applications. For this reason, applications built against C/C++ libraries with the help of compatibility libraries continue to be supported for ten years. There are two types of compatibility: - Source Compatibility
Source compatibility specifies that code will compile and execute in a consistent and predictable way across different instances of the operating environment. This type of compatibility is defined by conformance with specified Application Programming Interfaces (APIs). - Binary Compatibility
Binary Compatibility specifies that compiled binaries in the form of executables and Dynamic Shared Objects (DSOs) will run correctly across different instances of the operating environment. This type of compatibility is defined by conformance with specified Application Binary Interfaces (ABIs).
Source compatibility enables a body of application source code to be compiled and operate correctly on multiple instances of an operating environment, across one or more hardware architectures, as long as the source code is compiled individually for each specific hardware architecture. Source compatibility is defined by an Application Programming Interface (API), which is a set of programming interfaces and data structures provided to application developers. The programming syntax of APIs in the C programming language are defined in header files. These header files specify data types and programmatic functions. They are available to programmers for use in their applications, and are implemented by the operating system or libraries. The syntax of APIs are enforced at compile time, or when the application source code is compiled to produce executable binary objectcode. APIs are classified as: In all cases, application developers should seek to ensure that any behavior they depend on is described in formal API documentation, so as to avoid introducing dependencies on unspecified implementation specific semantics or even introducing dependencies on bugs in a particular implementation of an API. For example, new releases of the GNU C library are not guaranteed to be compatible with older releases if the old behavior violated a specification. Red Hat Enterprise Linux by and large seeks to implement source compatibility with a variety of de jure industry standards developed for Unix operating environments. While Red Hat Enterprise Linux does not fully conform to all aspects of these standards, the standards documents do provide a defined set of interfaces, and many components of Red Hat Enterprise Linux track compliance with them (particularly glibc, the GNU C Library, and gcc, the GNU C/C++/Java/Fortran Compiler). There are and will be certain aspects of the standards which are not implemented as required on Linux. A key set of standards that Red Hat seeks to conform with are those defined by the Austin Common Standards Revision Group ("The Austin Group"). The Austin Group is a working group formed in 1998 with the aim of unifying earlier Unix standardization efforts including ISO/IEC 9945�1 and 9945�2, IEEE Standards 1003.1 and 1003.2 (POSIX), and The Open Group's Single Unix Specification. The goal of The Austin Group is to unify the POSIX, ISO, and SUS standards into a single set of consistent standards. The Austin Group includes members from The Open Group, ISO, IEEE, major Unix vendors, and the open source community. The combined standards issued by The Austin Group carry both the IEEE POSIX designation and The Open Group's Technical Standard designation, and in the future the ISO/IEC designation. More information on The Austin Group is available at http://www.opengroup.org/austin/. Red Hat Enterprise Linux characterizes API compatibility four ways, with the most compatible APIs scored with the smallest number in the following list: No changes. Consumer should see no visible changes. Additions only. New structures, fields, header files, and exported interfaces may be added. Otherwise no visible changes allowed. Additions and Deprecations allowed. Structs, headers, fields, exported interfaces may be marked as deprecated or if previously marked as deprecated the headers, fields, exported interfaces, etc may be removed. Deprecated items may still exist as part of a compatibility layer in versioned libraries for ABI compatibility purposes, but are no longer available in APIs. Anything goes. No guarantees whatsoever are made.
In the following sections, these API classification levels will be detailed for select components of Red Hat Enterprise Linux. Binary compatibility enables a single compiled binary to operate correctly on multiple instances of an operating environment that share a common hardware architecture (whether that architecture support is implemented in native hardware or a virtualization layer), but a different underlying software architecture. Binary compatibility is defined by an Application Binary Interface (ABI). The ABI is a set of runtime conventions adhered to by all tools which deal with a compiled binary representation of a program. Examples of such tools include compilers, linkers, runtime libraries, and the operating system itself. The ABI includes not only the binary file formats, but also the semantics of library functions which are used by applications. Similar to the case of source compatibility, binary compatibility ABIs can be classified into the following: De facto standards, which are not formally specified but implied by a particular implementation. De jure standards, which are formally specified in standards documentation.
Red Hat Enterprise Linux by and large seeks to implement binary compatibility with a de jure industry standard developed for GNU/Linux operating environments, the Linux Standard Base (LSB). Red Hat Enterprise Linux 6 implements LSB version 4. Red Hat Enterprise Linux characterizes ABI compatibility four ways, with the most compatible ABIs scored with the smallest number in the following list: No changes made. Consumer should see no changes. Versioned additions only, no removals. New structures, fields, header files, and exported interfaces may be added as long as additional techniques are used to effectively version any new symbols. Applicable mechanisms for versioning external symbols include the use of compiler visibility support (via pragma, annotation, or suitable flag), use of language-specific features, or use of external link maps. Many of these techniques can be combined. Incompatible, but a separate compatibility library is packaged so that previously linked binaries can run without modification. Use is mutually exclusive: either the compatibility package is used, or the current package is used. Anything goes. Incompatible, with no recourse.
In the following sections, these ABI classification levels will be detailed for select components of Red Hat Enterprise Linux. 3.2.3.1. Compatibility Within A Major ReleaseOne of the core goals of the Red Hat Enterprise Linux family of products is to provide a stable, consistent runtime environment for custom application development. To support this goal, Red Hat seeks to preserve application binary compatibility, configuration file compatibility, and data file compatibility for all Red Hat Enterprise Linux 6 package updates issued within a major release. For example, a package update from Red Hat Enterprise Linux 6 Update 1 to Red Hat Enterprise Linux Update 2, or a package update that fixes an identified security vulnerability, should not break the functionality of deployed applications as long as they adhere to standard Application Binary Interfaces (ABIs) as previously discussed. 3.2.3.2. Compatibility Between Major ReleasesRed Hat Enterprise Linux also provides a level of compatibility across major releases, although it is less comprehensive than that provided within a major release. With the qualifications given below, Red Hat Enterprise Linux 6 provides runtime compatibility support for applications built for Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 4. For example, applications that are compiled with header files and linked to a particular version of glibc, the GNU C Library, are intended to continue to work with later versions of glibc. For the case of glibc, this is accomplished by providing versioned symbols, whose syntax and semantics are preserved in subsequent releases of the library even if a new, otherwise incompatible implementation is added. For other core system components, such as all 2.x releases of the GTK+ toolkit, backwards compatibility is ensured by limiting changes, which preserve the syntax and semantics of the defined APIs. In many cases, multiple versions of a particular library may be installed on a single system at the same time to support different versions of an API. An example is the inclusion of both Berkeley Database (db) version 4.7.25 and a compatibility version 4.3.29 in Red Hat Enterprise Linux 6, each with its own set of headers and libraries. Red Hat provides compatibility libraries for a set of core libraries. However, Red Hat does not guarantee compatibility across major releases of the distribution for dynamically linked libraries outside of the core library set unless versions of the Dynamic Shared Objects (DSOs) the application expects are provided (either as part of the application package or separate downloads). To ensure compatibility across major releases, application developers are encouraged to limit their dynamically linked library dependencies to those in the core library set, or to provide an independent version of the required non� core libraries packaged with their application (which in turn depend only on core libraries). As a rule, Red Hat recommends against statically linking libraries into applications. For more information on why we recommend against static linking, see Section 3.2.4, "Static Linking"Red Hat also reserves the right to remove particular packages between major releases. Red Hat provides a list of deprecated packages that may be removed in future versions of the product in the Release Notes for each major release. Application developers are advised to avoid using libraries on the deprecated list. Red Hat reserves the right to replace specific package implementations in future major releases with alternative packages that implement similar functionality. Red Hat does not guarantee compatibility of configuration file formats or data file formats between major releases of the distribution, although individual software packages may in fact provide file migration or compatibility support. 3.2.3.3. Building for forward compatibility across releasesIdeally, rebuild and repackage applications for each major release. This allows full advantage of new optimizations in the compiler, as well as new features available in the latest tools, to be taken. However, there are times when it is useful to build one set of binaries that can be deployed on multiple major releases at once. This is especially useful with old code bases that are not compliant to the latest revision of the language standards available in more recent Red Hat Enterprise Linux releases. Therefore it is advised to refer to the Red Hat Enterprise Linux 6 Application Compatibility Specification for guidance. This document outlines Red Hat policy and recommendations regarding backwards compatibility, particularly for specific packages. For example, if you would like to build a package that can be deployed in Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 5, and Red Hat Enterprise Linux 6 with one set of binaries, here are some general guidelines: Please note, that Red Hat only guarantees this forward compatibility between releases for the past two Enterprise Linux releases. That is, building on Red Hat Enterprise Linux 4 is guaranteed to work on Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6, provided you have the appropriate compatibility libraries on the latest two releases. Building on Red Hat Enterprise Linux 5 is guaranteed to work on Red Hat Enterprise Linux 6 and the next release thereafter. Static linking is emphatically discouraged for all Red Hat Enterprise Linux releases. Static linking causes far more problems than it solves, and should be avoided at all costs. The main drawback of static linking is that it is only guaranteed to work on the system on which it was built, and even then only until the next release of glibc or libstdc++ (in the case of C++). There is no forward or backward compatibility with a static build. Furthermore, any security fixes (or general-purpose fixes) in subsequent updates to the libraries will not be available unless the affected statically linked executables are re-linked. A few more reasons why static linking should be avoided are: Larger memory footprint. Slower application startup time. Reduced glibc features with static linking. Security measures like load address randomization cannot be used. Dynamic loading of shared objects outside of glibc is not supported.
Red Hat Enterprise Linux maintains a core set of libraries where the APIs and ABIs are preserved for each architecture across major releases (eg between Red Hat Enterprise Linux 5 and 6). This will help developers produce software that is compatible with a variety of Red Hat Enterprise Linux versions. Limit applications to linking against this set of libraries to take advantage of this feature. Table 3.2. Core Library Compatibility | Package Name | Files | Previous Red Hat Enterprise Linux Version | Notes |
|---|
| | 5 | 4 | |
|---|
| | API | ABI | API | ABI | |
|---|
| glibc | libc, libm, libdl, libutil, libcrypt | 2 | 2 | 3 | 2 | See notes for Red Hat Enterprise Linux 2 and 3. | | libstdc++ | libstdc++ | 2 | 2 | 3 | 2 | See notes for Red Hat Enterprise Linux 3. | | zlib | libz | 1 | | 1 | | | | ncurses-libs | libncurses | 1 | | 1 | | | | nss | libnss3, libssl3 | | | | | | | gtk2 | libgdk-x11-2.0, libgdk_pixbuf-2.0, libgtk-x11-2.0 | 2 | | | | | | glib2 | libglib-2.0, libgmodule-2.0, libgthread-2.0, | 2 | | | | |
If an application can not limit itself to the interfaces of these core libraries, then to ensure compatibility across major releases, the application should bundle the additional required libraries as part of the application itself. In that case, the bundled libraries must themselves use only the interfaces provided by the core libraries. 3.2.6. Non-Core LibrariesRed Hat Enterprise Linux also includes a wide range of libraries whose APIs and ABIs are not guaranteed to be preserved between major releases. Compatibility of these libraries is, however, provided within a major release of the distribution. Applications are free to use these non-�core libraries, but to ensure compatibility across major releases, application vendors should provide their own copies of these non�-core libraries, which in turn should depend only on the core libraries listed in the previous section. Table 3.3. Non-Core Library Compatibility | Package Name | Files | Previous Red Hat Enterprise Linux Version |
|---|
| 5 | 4 |
|---|
| API | ABI | API | ABI |
|---|
| boost | libboost_filesystem, libboost_threads | 4 | 4 | 4 | 4 | | openssl | libssl, libcrypto | 4 | 3 | 4 | 4 | | gcc | libitm | 4 | 4 | | |
3.3. Library and Runtime Detailscompat-glibc provides a subset of the shared static libraries from previous versions of Red Hat Enterprise Linux. For Red Hat Enterprise Linux 6, the following libraries are provided:
libanl
libcidn
libcrypt
libc
libdl
libm
libnsl
libpthread
libresolv
librt
libthread_db
libutil
This set of libraries allows developers to create a Red Hat Enterprise Linux 5 application with Red Hat Enterprise Linux 6, provided the application uses only the above libraries. Use the following command to do so: # gcc -fgnu89-inline -I /usr/lib/x86_64-redhat-linux5E/include -B /usr/lib/x86_64-redhat-linux5E/lib64/ -lc_nonshared
3.3.2. The GNU C++ Standard LibraryThe libstdc++ package contains the GNU C++ Standard Library, which is an ongoing project to implement the ISO 14882 Standard C++ library. Installing the libstdc++ package will provide just enough to satisfy link dependencies (that is, only shared library files). To make full use of all available libraries and header files for C++ development, you must install libstdc++-devel as well. The libstdc++-devel package also contains a GNU-specific implementation of the Standard Template Library (STL). For Red Hat Enterprise Linux 4, 5, and 6, the C++ language and runtime implementation has remained stable and as such no compatibility libraries are required for libstdc++. However, this is not the case for Red Hat Enterprise Linux 2 and 3. For Red Hat Enterprise Linux 2 compat-libstdc++-296 is required to be installed. For Red Hat Enterprise Linux 3 compat-libstdc++-33 is required to be installed. Neither of these are installed by default so have to be added separately. 3.3.2.1. GNU C++ Standard Library Updates The Red Hat Enterprise Linux 6 version of the GNU C++ Standard Library features the following improvements over its Red Hat Enterprise Linux 5 version: Added support for elements of ISO C++ TR1, namely: <tr1/array>
<tr1/complex>
<tr1/memory>
<tr1/functional>
<tr1/random>
<tr1/regex>
<tr1/tuple>
<tr1/type_traits>
<tr1/unordered_map>
<tr1/unordered_set>
<tr1/utility>
<tr1/cmath>
Added support for elements of the upcoming ISO C++ standard, C++0x. These elements include: <array>
<chrono>
<condition_variable>
<forward_list>
<functional>
<initalizer_list>
<mutex>
<random>
<ratio>
<regex>
<system_error>
<thread>
<tuple>
<type_traits>
<unordered_map>
<unordered_set>
Added support for the -fvisibility command. Added the following extensions:
For more information about updates to libstdc++ in Red Hat Enterprise Linux 6, refer to the C++ Runtime Library section of the following documents: 3.3.2.2. GNU C++ Standard Library Documentation To use the man pages for library components, install the libstdc++-docs package. This will provide man page information for nearly all resources provided by the library; for example, to view information about the vector container, use its fully-qualified component name: man std::vector
This will display the following information (abbreviated): The libstdc++-docs package also provides manuals and reference information in HTML form at the following directory: file:///usr/share/doc/libstdc++-docs-version/html/spine.html
The main site for the development of libstdc++ is hosted on gcc.gnu.org. The boost package contains a large number of free peer-reviewed portable C++ source libraries. These libraries are suitable for tasks such as portable file-systems and time/date abstraction, serialization, unit testing, thread creation and multi-process synchronization, parsing, graphing, regular expression manipulation, and many others. Installing the boost package will provide just enough libraries to satisfy link dependencies (that is, only shared library files). To make full use of all available libraries and header files for C++ development, you must install boost-devel as well. The boost package is actually a meta-package, containing many library sub-packages. These sub-packages can also be installed individually to provide finer inter-package dependency tracking. The meta-package includes all of the following sub-packages: boost-date-time
boost-filesystem
boost-graph
boost-iostreams
boost-math
boost-program-options
boost-python
boost-regex
boost-serialization
boost-signals
boost-system
boost-test
boost-thread
boost-wave
Not included in the meta-package are packages for static linking or packages that depend on the underlying Message Passing Interface (MPI) support. MPI support is provided in two forms: one for the default Open MPI implementation , and another for the alternate MPICH2 implementation. The selection of the underlying MPI library in use is up to the user and depends on specific hardware details and user preferences. Please note that these packages can be installed in parallel, as installed files have unique directory locations. For Open MPI: boost-openmpi
boost-openmpi-devel
boost-graph-openmpi
boost-openmpi-python
For MPICH2: boost-mpich2
boost-mpich2-devel
boost-graph-mpich2
boost-mpich2-python
If static linkage cannot be avoided, the boost-static package will install the necessary static libraries. Both thread-enabled and single-threaded libraries are provided. The Red Hat Enterprise Linux 6 version of Boost features many packaging improvements and new features. Several aspects of the boost package have changed. As noted above, the monolithic boost package has been augmented by smaller, more discrete sub-packages. This allows for more control of dependencies by users, and for smaller binary packages when packaging a custom application that uses Boost. In addition, both single-threaded and multi-threaded versions of all libraries are packaged. The multi-threaded versions include the mt suffix, as per the usual Boost convention. Boost also features the following new libraries: Many of the existing libraries have been improved, bug-fixed, and otherwise enhanced. 3.3.3.2. Boost DocumentationThe boost-doc package provides manuals and reference information in HTML form located in the following directory: file:///usr/share/doc/boost-doc-version/index.html
The main site for the development of Boost is hosted on boost.org. The qt package provides the Qt (pronounced "cute") cross-platform application development framework used in the development of GUI programs. Aside from being a popular "widget toolkit", Qt is also used for developing non-GUI programs such as console tools and servers. Qt was used in the development of notable projects such as Google Earth, KDE, Opera, OPIE, VoxOx, Skype, VLC media player and VirtualBox. It is produced by Nokia's Qt Development Frameworks division, which came into being after Nokia's acquisition of the Norwegian company Trolltech, the original producer of Qt, on June 17, 2008. Qt uses standard C++ but makes extensive use of a special pre-processor called the Meta Object Compiler (MOC) to enrich the language. Qt can also be used in other programming languages via language bindings. It runs on all major platforms and has extensive internationalization support. Non-GUI Qt features include SQL database access, XML parsing, thread management, network support, and a unified cross-platform API for file handling. Distributed under the terms of the GNU Lesser General Public License (among others), Qt is free and open source software. The Red Hat Enterprise Linux 6 version of Qt supports a wide range of compilers, including the GCC C++ compiler and the Visual Studio suite. Some of the improvements the Red Hat Enterprise Linux 6 version of Qt include: Advanced user experience options for opacity, drop-shadows, blur, colorization, and other similar effects create simple or complex animations without the hassle of managing complex code Gesture and multi-touch support
Support for new platforms Windows 7, Mac OSX 10.6, and other desktop platforms are now supported Added support for mobile development; Qt is optimized for the upcoming Maemo 6 platform, and will soon be ported to Maemo 5. In addition, Qt now supports the Symbian platform, with integration for the S60 framework. Added support for Real-Time Operating Systems such as QNX and VxWorks
Improved performance, featuring added support for hardware-accelerated rendering (along with other rendering updates) Updated cross-platform IDE
For more details on updates to Qt included in Red Hat Enterprise Linux 6, refer to the following links: Qt Creator is a cross-platform IDE tailored to the requirements of Qt developers. It includes the following graphical tools: An advanced C++ code editor Integrated GUI layout and forms designer Project and build management tools Integrated, context-sensitive help system Visual debugger Rapid code navigation tools
For more information about Qt Creator, refer to the following link: 3.3.4.3. Qt Library DocumentationThe qt-doc package provides HTML manuals and references located in /usr/share/doc/qt4/html/. This package also provides the Qt Reference Documentation, which is an excellent starting point for development within the Qt framework. You can also install further demos and examples from qt-demos and qt-examples. To get an overview of the capabilities of the Qt framework, refer to /usr/bin/qtdemo-qt4 (provided by qt-demos). For more information on the development of Qt, refer to the following online resources: 3.3.5. KDE Development FrameworkThe kdelibs-devel package provides the KDE libraries, which build on Qt to provide a framework for making application development easier. The KDE development framework also helps provide consistency across the KDE desktop environment. 3.3.5.1. KDE4 ArchitectureThe KDE development framework's architecture in Red Hat Enterprise Linux 6 uses KDE4, which is built on the following technologies: - Plasma
- Sonnet
Sonnet is a multilingual spell-checking application that supports automatic language detection, primary/backup dictionaries, and other useful features. It replaces kspell2 in KDE4. - KIO
The KIO library provides a framework for network-transparent file handling, allowing users to easily access files through network-transparent protocols. It also helps provides standard file dialogs. - KJS/KHTML
KJS and KHTML are fully-fledged JavaScript and HTML engines used by different applications native to KDE4 (such as konqueror). - Solid
Solid is a hardware and network awareness framework that allows you to develop applications with hardware interaction features. Its comprehensive API provides the necessary abstraction to support cross-platform application development. For more information, refer to http://techbase.kde.org/Development/Architecture/KDE4/Solid. - Phonon
- Telepathy
- Akonadi
- Online Help within KDE4
- KXMLGUI
- Strigi
Strigi is a desktop search daemon compatible with many desktop environments and operating systems. It uses its own jstream system which allows for deep indexing of files. For more information on the development of Strigi, refer to http://www.vandenoever.info/software/strigi/. - KNewStuff2
3.3.5.2. kdelibs DocumentationThe kdelibs-apidocs package provides HTML documentation for the KDE development framework in /usr/share/doc/HTML/en/kdelibs4-apidocs/. The following links also provide details on KDE-related programming tasks: 3.3.6. GNOME Power ManagerThe backend program of the GNOME power management infrastructure is gnome-power-manager. It was introduced in Red Hat Enterprise Linux 5 and provides a complete and integrated solution to power management under the GNOME desktop environment. In Red Hat Enterprise Linux 6, the storage-handling parts of hal was replaced by udisks, and the libgnomeprint stack was replaced by print support in gtk2. 3.3.6.1. GNOME Power Management Version GuideThis section will detail what versions of gnome-power-management are shipped with the various Red Hat Enterprise Linux versions. In general, however, Red Hat Enterprise Linux 4 ships with GNOME 2.8, Red Hat Enterprise Linux 5 ships with GNOME 2.16, and Red Hat Enterprise Linux 6 ships with GNOME 2.28. Table 3.4. Desktop Components Comparison | Red Hat Enterprise Linux Version |
|---|
GNOME Power Management Desktop Components | 4 | 5 | 6 |
|---|
hal | 0.4.2 | 0.5.8 | 0.5.14 | udisks | N/A | N/A | 1.0.1 | glib2 | 2.4.7 | 2.12.3 | 2.22.5 | gtk2 | 2.4.13 | 2.10.4 | 2.18.9 | gnome-vfs2 | 2.8.2 | 2.16.2 | 2.24.2 | libglade2 | 2.4.0 | 2.6.0 | 2.6.4 | libgnomecanvas | 2.8.0 | 2.14.0 | 2.26.0 | gnome-desktop | 2.8.0 | 2.16.0 | 2.28.2 | gnome-media | 2.8.0 | 2.16.1 | 2.29.91 | gnome-python2 | 2.6.0 | 2.16.0 | 2.28.0 | libgnome | 2.8.0 | 2.16.0 | 2.28.0 | libgnomeui | 2.8.0 | 2.16.0 | 2.24.1 | libgnomeprint22 | 2.8.0 | 2.12.1 | N/A | libgnomeprintui22 | 2.8.0 | 2.12.1 | N/A | gnome-session | 2.8.0 | 2.16.0 | 2.28.0 | gnome-power-manager | N/A | 2.16.0 | 2.28.3 | gnome-applets | 2.8.0 | 2.16.0 | 2.28.0 | gnome-panel | 2.8.1 | 2.16.1 | 2.30.2 |
3.3.6.2. API Changes for glibThere are a number of API changes for glib between versions. GOption (a command line option parser) GKeyFile (a key/ini file parser) GObject toggle references GMappedFile (a map wrapper) GSlice (a fast memory allocator) GBookmarkFile (a bookmark file parser) Base64 encoding support Native atomic ops on s390 Updated Unicode support to 5 Atomic reference counting for GObject
GSequence (a list data structure that is implemented as a balanced tree) GRegex (a PCRE regex wrapper) Support for monotonic clocks XDG user dirs support GIO (a VFS library to replace gnome-vfs) GChecksum (support for hash algorithms such as MD5 and SHA-256) GTest (a test framework) Support for sockets and network IO in GIO GHashTable performance improvements GMarkup performance improvements
Documentation for glib, including indexes of new and deprecated APIs, is shipped in the glib2-devel package. 3.3.6.3. API Changes for GTK+There are a number of API changes for GTK+ between versions. Documentation for GTK+, including indexes of new and deprecated APIs, is shipped in the gtk2-devel package. 3.3.7. NSS Shared DatabasesThe NSS shared database format, introduced on NSS 3.12, is now available in Red Hat Enterprise 6. This encompasses a number of new features and components to improve access and usability. Included, is the NSS certificate and key database which are now sqlite-based and allow for concurrent access. The legacy key3.db and cert8.db are also replaced with new SQL databases called key4.db and cert9.db. These new databases will store PKCS #11 token objects, which are the same as what is currently stored in cert8.db and key3.db. Having support for shared databases enables a system-wide NSS database. It resides in /etc/pki/nssdb where globally trusted CA certificates become accessible to all applications. The command rv = NSS_InitReadWrite("sql:/etc/pki/nssdb"); initializes NSS for applications. If the application is run with root privileges, then the system-wide database is available on a read and write basis. However, if it is run with normal user privileges it becomes read only. Additionally, a PEM PKCS #11 module for NSS allows applications to load into memory certificates and keys stored in PEM-formatted files (for example, those produced by openssl). 3.3.7.1. Backwards CompatibilityThe binary compatibility guarantees made by NSS upstream are preserved in NSS for Red Hat Enterprise Linux 6. This guarantee states that the NSS 3.12 is backwards compatible with all older NSS 3.x shared libraries. Therefore, a program linked with an older NSS 3.x shared library will work without recompiling or relinking, and any applications that restrict the use of NSS APIs to the NSS Public Functions remain compatible with future versions of the NSS shared libraries. Red Hat Enterprise Linux 5 and 4 run on the same version of NSS as Red Hat Enterprise Linux 6 so there are no ABI or API changes. However, there are still differences as NSS's internal cryptographic module in Red Hat Enterprise Linux 6 is the one from NSS 3.12, whereas Red Hat Enterprise Linux 5 and 4 still use the older one from NSS 3.15. This means that new functionality that had been introduced with NSS 3.12, such as the shared database, is now available with Red Hat Enterprise Linux 6's version of NSS. 3.3.7.2. NSS Shared Databases DocumentationMozilla's wiki page explains the system-wide database rationale in great detail and can be accessed here. The python package adds support for the Python programming language. This package provides the object and cached bytecode files required to enable runtime support for basic Python programs. It also contains the python interpreter and the pydoc documentation tool. The python-devel package contains the libraries and header files required for developing Python extensions. Red Hat Enterprise Linux also ships with numerous python-related packages. By convention, the names of these packages have a python prefix or suffix. Such packages are either library extensions or python bindings to an existing library. For instance, dbus-python is a Python language binding for D-Bus. Note that both cached bytecode (*.pyc*.pyo*.so The Red Hat Enterprise Linux 6 version of Python features various language changes. For information about these changes, refer to the following project resources: Both resources also contain advice on porting code developed using previous Python versions. 3.3.8.2. Python DocumentationFor more information about Python, refer to man python. You can also install python-docs, which provides HTML manuals and references in the following location: file:///usr/share/doc/python-docs-version/html/index.html
For details on library and language components, use pydoc component_name. For example, pydoc math will display the following information about the math Python module: Help on module math:NAMEmathFILE/usr/lib64/python2.6/lib-dynload/mathmodule.soDESCRIPTIONThis module is always available. It provides access to themathematical functions defined by the C standard.FUNCTIONSacos[...]acos(x)Return the arc cosine (measured in radians) of x.acosh[...]acosh(x)Return the hyperbolic arc cosine (measured in radians) of x.asin(...)asin(x)Return the arc sine (measured in radians) of x.asinh[...]asinh(x)Return the hyperbolic arc sine (measured in radians) of x. The main site for the Python development project is hosted on python.org. The java-1.6.0-openjdk package adds support for the Java programming language. This package provides the java interpreter. The java-1.6.0-openjdk-devel package contains the javac compiler, as well as the libraries and header files required for developing Java extensions. Red Hat Enterprise Linux also ships with numerous java-related packages. By convention, the names of these packages have a java prefix or suffix. 3.3.9.1. Java Documentation For more information about Java, refer to man java. Some associated utilities also have their own respective man pages. You can also install other Java documentation packages for more details about specific Java utilities. By convention, such documentation packages have the javadoc suffix (for example, dbus-java-javadoc). The ruby package provides the Ruby interpreter and adds support for the Ruby programming language. The ruby-devel package contains the libraries and header files required for developing Ruby extensions. Red Hat Enterprise Linux also ships with numerous ruby-related packages. By convention, the names of these packages have a ruby or rubygem prefix or suffix. Such packages are either library extensions or Ruby bindings to an existing library. Examples of ruby-related packages include: ruby-flexmock rubygem-flexmock rubygems ruby-irb ruby-libguestfs ruby-libs ruby-qpid ruby-rdoc ruby-ri ruby-saslwrapper ruby-static ruby-tcltk
For information about updates to the Ruby language in Red Hat Enterprise Linux 6, refer to the following resources: 3.3.10.1. Ruby DocumentationFor more information about Ruby, refer to man ruby. You can also install ruby-docs, which provides HTML manuals and references in the following location: file:///usr/share/doc/ruby-docs-version/
The perl package adds support for the Perl programming language. This package provides Perl core modules, the Perl Language Interpreter, and the PerlDoc tool. Red Hat also provides various perl modules in package form; these packages are named with the perl-* prefix. These modules provide stand-alone applications, language extensions, Perl libraries, and external library bindings. An RPM package can contain more perl modules. Each module intended for public use is provided by the package, in the form of perl(The::Module). This expression can be parsed to yum to install the appropriate packages. Red Hat Enterprise Linux 7 ships with perl-5.16. If you are running an older system, rebuild or alter external modules and applications accordingly in order to ensure optimum performance. For a full list of the differences between the Perl versions refer to the following documents: - Perl 5.12 Updates
Perl 5.12 has the following updates: Perl conforms closer to the Unicode standard. Experimental APIs allow Perl to be extended with "pluggable" keywords and syntax. Perl will be able to keep accurate time well past the "Y2038" barrier. Package version numbers can be directly specified in "package" statements. Perl warns the user about the use of depreciated features by default.
- Perl 5.14 Updates
Perl 5.14 has the following updates: Unicode 6.0 support. Improved support for IPv6. Easier auto-configuration of the CPAN client. A new /r flag that makes s/// substitutions non-destructive. New regular expression flags to control whether matched strings should be treated as ASCII or Unicode. New package Foo { } syntax. Less memory and CPU usage than previous releases. A number of bug fixes.
- Perl 5.16 Updates
Perl 5.14 has the following updates: Support for Unicode 6.1. $$ variable is writable.
Improved debugger. Accessing Unicode database files directly is now depreciated; use Unicode::UCD instead. Version::Requirements is depreciated in favor of CPAN::Meta::Requirements.
A number of perl4 libraries are removed: abbrev.pl assert.pl bigfloat.pl bigint.pl bigrat.pl cacheout.pl complete.pl ctime.pl dotsh.pl exceptions.pl fastcwd.pl flush.pl getcwd.pl getopt.pl getopts.pl hostname.pl importenv.pl lib/find{,depth}.pl look.pl newgetopt.pl open2.pl open3.pl pwd.pl hellwords.pl stat.pl tainted.pl termcap.pl timelocal.pl
Perl's capabilities can be extended by installing additional modules. These modules come in the following forms: - Official Red Hat RPM
The official module packages can be installed with yum or rpm from the Red Hat Enterprise Linux repositories. They are installed to /usr/share/perl5 and either /usr/lib/perl5 for 32bit architectures or /usr/lib64/perl5 for 64bit architectures. - Modules from CPAN
Use the cpan tool provided by the perl-CPAN package to install modules directly from the CPAN website. They are installed to /usr/local/share/perl5 and either /usr/local/lib/perl5 for 32bit architectures or /usr/local/lib64/perl5 for 64bit architectures. - Third party module package
Third party modules are installed to /usr/share/perl5/vendor_perl and either /usr/lib/perl5/vendor_perl for 32bit architectures or /usr/lib64/perl5/vendor_perl for 64bit architectures. - Custom module package / manually installed module
These should be placed in the same directories as third-party modules. That is, /usr/share/perl5/vendor_perl and either /usr/lib/perl5/vendor_perl for 32bit architectures or /usr/lib64/perl5/vendor_perl for 64bit architectures.
If an official version of a module is already installed, installing its non-official version can create conflicts in the /usr/share/man directory. 3.3.11.3. Perl DocumentationThe perldoc tool provides documentation on language and core modules. To learn more about a module, use perldoc module_name. For example, perldoc CGI will display the following information about the CGI core module: NAME CGI - Handle Common Gateway Interface requests and responses SYNOPSIS use CGI; my $q = CGI->new; [...] DESCRIPTION CGI.pm is a stable, complete and mature solution for processing and preparing HTTP requests and responses. Major features including processing form submissions, file uploads, reading and writing cookies, query string generation and manipulation, and processing and preparing HTTP headers. Some HTML generation utilities are included as well. [...] PROGRAMMING STYLE There are two styles of programming with CGI.pm, an object-oriented style and a function-oriented style. In the object-oriented style you create one or more CGI objects and then use object methods to create the various elements of the page. Each CGI object starts out with the list of named parameters that were passed to your CGI script by the server. [...] For details on Perl functions, use perldoc -f function_name . For example, perldoc -f split wil display the following information about the split function: split /PATTERN/,EXPR,LIMIT split /PATTERN/,EXPR split /PATTERN/ split Splits the string EXPR into a list of strings and returns that list. By default, empty leading fields are preserved, and empty trailing ones are deleted. (If all fields are empty, they are considered to be trailing.) In scalar context, returns the number of fields found. In scalar and void context it splits into the @_ array. Use of split in scalar and void context is deprecated, however, because it clobbers your subroutine arguments. If EXPR is omitted, splits the $_ string. If PATTERN is also omitted, splits on whitespace (after skipping any leading whitespace). Anything matching PATTERN is taken to be a delimiter separating the fields. (Note that the delimiter may be longer than one character.) [...] |
| |
