Chapter 4. Compiling and Building

Red Hat Enterprise Linux 6 includes many packages used for software development, including tools for compiling and building source code. This chapter discusses several of these packages and tools used to compile source code.

4.1. GNU Compiler Collection (GCC)

The GNU Compiler Collection (GCC) is a set of tools for compiling a variety of programming languages (including C, C++, ObjectiveC, ObjectiveC++, Fortran, and Ada) into highly optimized machine code. These tools include various compilers (like gcc and g++), run-time libraries (like libgcc, libstdc++, libgfortran, and libgomp), and miscellaneous other utilities.

4.1.1. GCC Status and Features

GCC for Red Hat Enterprise Linux 6 is based on the 4.4.x release series and includes several bug fixes, enhancements, and backports from upcoming releases (including the GCC 4.5). However, GCC 4.5 was not considered sufficiently mature for an enterprise distribution when Red Hat Enterprise Linux 6 features were frozen.

This standardization means that as updates to the 4.4 series become available (4.4.1, 4.4.2, and so on), they will be incorporated into the compiler included with Red Hat Enterprise Linux 6 as updates. Red Hat may import additional backports and enhancements from upcoming releases outside the 4.4 series that will not break compatibility within the Enterprise Linux release. Occasionally, code that was not compliant to standards may fail to compile or its functionality may change in the process of fixing bugs or maintaining standards compliant behavior.

Since the previous release of Red Hat Enterprise Linux, GCC has had three major releases: 4.2.x, 4.3.x, and 4.4.x. A selective summary of the expansive list of changes follows.

The inliner, dead code elimination routines, compile time, and memory usage codes are now improved. This release also features a new register allocator, instruction scheduler, and software pipeliner.
Version 3.0 of the OpenMP specification is now supported for the C, C++, and Fortran compilers.
Experimental support for the upcoming ISO C++ standard (C++0x) is included. This has support for auto/inline namespaces, character types, and scoped enumerations. To enable this, use the compiler options -std=c++0x (which disables GNU extensions) or -std=gnu++0x.
For a more detailed list of the status of C++0x improvements, refer to:
http://gcc.gnu.org/gcc-4.4/cxx0x_status.html
GCC now incorporates the Variable Tracking at Assignments (VTA) infrastructure. This allows GCC to better track variables during optimizations so that it can produce improved debugging information (that is, DWARF) for the GNU Project Debugger, SystemTap, and other tools. For a brief overview of VTA, refer to Section 5.4, "Variable Tracking at Assignments".
With VTA you can debug optimized code drastically better than with previous GCC releases, and you do not have to compile with -O0 to provide a better debugging experience.
Fortran 2008 is now supported, while support for Fortran 2003 is extended.

For a more detailed list of improvements in GCC, refer to:

Updates in the 4.2 Series: http://gcc.gnu.org/gcc-4.2/changes.html
Updates in the 4.3 Series: http://gcc.gnu.org/gcc-4.3/changes.html
Updates in the 4.4 Series: http://gcc.gnu.org/gcc-4.4/changes.html

In addition to the changes introduced via the GCC 4.4 rebase, the Red Hat Enterprise Linux 6 version of GCC also features several fixes and enhancements backported from upstream sources (that is, version 4.5 and beyond). These improvements include the following (among others):

Improved DWARF3 debugging for debugging optimized C++ code.
Fortran optimization improvements.
More accurate instruction length information for ix86, Intel 64 and AMD64, and s390.
Intel Atom support.
POWER7 support.
C++ raw string support, u/U/u8 string literal support.

4.1.2. Language Compatibility

Application Binary Interfaces specified by the GNU C, C++, Fortran and Java Compiler include:

Calling conventions. These specify how arguments are passed to functions and how results are returned from functions.
Register usage conventions. These specify how processor registers are allocated and used.
Object file formats. These specify the representation of binary object code.
Size, layout, and alignment of data types. These specify how data is laid out in memory.
Interfaces provided by the runtime environment. Where the documented semantics do not change from one version to another they must be kept available and use the same name at all times.

The default system C compiler included with Red Hat Enterprise Linux 6 is largely compatible with the C99 ABI standard. Deviations from the C99 standard in GCC 4.4 are tracked online.

In addition to the C ABI, the Application Binary Interface for the GNU C++ Compiler specifies the binary interfaces required to support the C++ language, such as:

Name mangling and demangling
Creation and propagation of exceptions
Formatting of run-time type information
Constructors and destructors
Layout, alignment, and padding of classes and derived classes
Virtual function implementation details, such as the layout and alignment of virtual tables

The default system C++ compiler included with Red Hat Enterprise Linux 6 conforms to the C++ ABI defined by the Itanium C++ ABI (1.86).

Although every effort has been made to keep each version of GCC compatible with previous releases, some incompatibilities do exist.

ABI incompatibilities between Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 5

The following is a list of known incompatibilities between the Red Hat Enterprise Linux 6 and 5 toolchains.

Passing/returning structs with flexible array members by value changed in some cases on Intel 64 and AMD64.
Passing/returning of unions with long double members by value changed in some cases on Intel 64 and AMD64.
Passing/returning structs with complex float member by value changed in some cases on Intel 64 and AMD64.
Passing of 256-bit vectors on x86, Intel 64 and AMD64 platforms changed when -mavx is used.
There have been multiple changes in passing of _Decimal{32,64,128} types and aggregates containing those by value on several targets.
Packing of packed char bitfields changed in some cases.

ABI incompatibilities between Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 4

The following is a list of known incompatibilities between the Red Hat Enterprise Linux 5 and 4 toolchains.

There have been changes in the library interface specified by the C++ ABI for thread-safe initialization of function-scope static variables.
On Intel 64 and AMD64, the medium model for building applications where data segment exceeds 4GB, was redesigned to match the latest ABI draft at the time. The ABI change results in incompatibility among medium model objects.

The compiler flag -Wabi can be used to get diagnostics indicating where these constructs appear in source code, though it will not catch every single case. This flag is especially useful for C++ code to warn whenever the compiler generates code that is known to be incompatible with the vendor-neutral C++ ABI.

Excluding the incompatibilities listed above, the GCC C and C++ language ABIs are mostly ABI compatible. The vast majority of source code will not encounter any of the known issues, and can be considered compatible.

Compatible ABIs allow the objects created by compiling source code to be portable to other systems. In particular, for Red Hat Enterprise Linux, this allows for upward compatibility. Upward compatibility is defined as the ability to link shared libraries and objects, created using a version of the compilers in a particular Red Hat Enterprise Linux release, with no problems. This includes new objects compiled on subsequent Red Hat Enterprise Linux releases.

The C ABI is considered to be stable, and has been so since at least Red Hat Enterprise Linux 3 (again, barring any incompatibilities mentioned in the above lists). Libraries built on Red Hat Enterprise Linux 3 and later can be linked to objects created on a subsequent environment (Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 5, and Red Hat Enterprise Linux 6).

The C++ ABI is considered to be stable, but less stable than the C ABI, and only as of Red Hat Enterprise Linux 4 (corresponding to GCC version 3.4 and above.). As with C, this is only an upward compatibility. Libraries built on Red Hat Enterprise Linux 4 and above can be linked to objects created on a subsequent environment (Red Hat Enterprise Linux 5, and Red Hat Enterprise Linux 6).

To force GCC to generate code compatible with the C++ ABI in Red Hat Enterprise Linux releases prior to Red Hat Enterprise Linux 4, some developers have used the -fabi-version=1 option. This practice is not recommended. Objects created this way are indistinguishable from objects conforming to the current stable ABI, and can be linked (incorrectly) amongst the different ABIs, especially when using new compilers to generate code to be linked with old libraries that were built with tools prior to Red Hat Enterprise Linux 4.

Warning

The above incompatibilities make it incredibly difficult to maintain ABI shared library sanity between releases, especially when developing custom libraries with multiple dependencies outside of the core libraries. Therefore, if shared libraries are developed, it is highly recommend that a new version is built for each Red Hat Enterprise Linux release.

4.1.3. Object Compatibility and Interoperability

Two items that are important are the changes and enhancements in the underlying tools used by the compiler, and the compatibility between the different versions of a language's compiler.

Changes and new features in tools like ld (distributed as part of the binutils package) or in the dynamic loader (ld.so, distributed as part of the glibc package) can subtly change the object files that the compiler produces. These changes mean that object files moving to the current release of Red Hat Enterprise Linux from previous releases may lose functionality, behave differently at runtime, or otherwise interoperate in a diminished capacity. Known problem areas include:

ld --build-id
In Red Hat Enterprise Linux 6 this is passed to ld by default, whereas Red Hat Enterprise Linux 5 ld doesn't recognize it.
as .cfi_sections support
In Red Hat Enterprise Linux 6 this directive allows .debug_frame, .eh_frame or both to be omitted from .cfi* directives. In Red Hat Enterprise Linux 5 only .eh_frame is omitted.
as, ld, ld.so, and gdb STB_GNU_UNIQUE and %gnu_unique_symbol support
In Red Hat Enterprise Linux 6 more debug information is generated and stored in object files. This information relies on new features detailed in the DWARF standard, and also on new extensions not yet standardized. In Red Hat Enterprise Linux 5, tools like as, ld, gdb, objdump, and readelf may not be prepared for this new information and may fail to interoperate with objects created with the newer tools. In addition, Red Hat Enterprise Linux 5 produced object files do not support these new features; these object files may be handled by Red Hat Enterprise Linux 6 tools in a sub-optimal manner.
An outgrowth of this enhanced debug information is that the debuginfo packages that ship with system libraries allow you to do useful source level debugging into system libraries if they are installed. Refer to Section 5.2, "Installing Debuginfo Packages" for more information on debuginfo packages.

Object file changes, such as the ones listed above, may interfere with the portable use of prelink.

4.1.4. Backwards Compatibility Packages

Several packages are provided to serve as an aid for those moving source code or executables from older versions of Red Hat Enterprise Linux to the current release. These packages are intended to be used as a temporary aid in transitioning sources to newer compilers with changed behavior, or as a convenient way to otherwise isolate differences in the system environment from the compile environment.

Note

Please be advised that Red Hat may remove these packages in future Red Hat Enterprise Linux releases.

The following packages provide compatibility tools for compiling Fortran or C++ source code on the current release of Red Hat Enterprise Linux 6 as if one was using the older compilers on Red Hat Enterprise Linux 4:

compat-gcc-34
compat-gcc-34-c++
compat-gcc-34-g77

The following package provides a compatibility runtime library for Fortran executables compiled on Red Hat Enterprise Linux 5 to run without recompilation on the current release of Red Hat Enterprise Linux 6:

compat-libgfortran-41

Please note that backwards compatibility library packages are not provided for all supported system libraries, just the system libraries pertaining to the compiler and the C/C++ standard libraries.

For more information about backwards compatibility library packages, refer to the Application Compatibility section of the Red Hat Enterprise Linux 6 Migration Guide.

4.1.5. Previewing Red Hat Enterprise Linux 6 compiler features on Red Hat Enterprise Linux 5

On Red Hat Enterprise Linux 5, we have included the package gcc44 as an update. This is a backport of the Red Hat Enterprise Linux 6 compiler to allow users running Red Hat Enterprise Linux 5 to compile their code with the Red Hat Enterprise Linux 6 compiler and experiment with new features and optimizations before upgrading their systems to the next major release. The resulting binary will be forward compatible with Red Hat Enterprise Linux 6, so it can be compiled on Red Hat Enterprise Linux 5 with gcc44 and run on Red Hat Enterprise Linux 5, Red Hat Enterprise Linux 6, and above.

The Red Hat Enterprise Linux 5 gcc44 compiler will be kept reasonably in step with the GCC 4.4.x that we ship with Red Hat Enterprise Linux 6 to ease transition. Though, to get the latest features, it is recommended Red Hat Enterprise Linux 6 is used for development. The gcc44 is only provided as an aid in the conversion process.

4.1.6. Running GCC

To compile using GCC tools, first install binutils and gcc; doing so will also install several dependencies.

In brief, the tools work via the gcc command. This is the main driver for the compiler. It can be used from the command line to pre-process or compile a source file, link object files and libraries, or perform a combination thereof. By default, gcc takes care of the details and links in the provided libgcc library.

The compiler functions provided by GCC are also integrated into the Eclipse IDE as part of the CDT. This presents many advantages, particularly for developers who prefer a graphical interface and fully integrated environment.

Conversely, using GCC tools from the command line interface consumes less system resources. This also allows finer-grained control over compilers; GCC's command line tools can even be used outside of the graphical mode (runlevel 5).

4.1.6.1. Simple C Usage

Basic compilation of a C language program using GCC is easy. Start with the following simple program:

hello.c

#include <stdio.h>int main (){  printf ("Hello world!\n");  return 0;}

The following procedure illustrates the compilation process for C in its most basic form.

Procedure 4.1. Compiling a 'Hello World' C Program

Compile hello.c into an executable with:
gcc hello.c -o hello
Ensure that the resulting binary hello is in the same directory as hello.c.
Run the hello binary, that is, hello.

4.1.6.2. Simple C++ Usage

Basic compilation of a C++ language program using GCC is similar. Start with the following simple program:

hello.cc

#include <iostream>using namespace std;int main(void){  cout << "Hello World!" << endl;  return 0;}

The following procedure illustrates the compilation process for C++ in its most basic form.

Procedure 4.2. Compiling a 'Hello World' C++ Program

Compile hello.cc into an executable with:
g++ hello.cc -o hello
Ensure that the resulting binary hello is in the same directory as hello.cc.
Run the hello binary, that is, hello.

4.1.6.3. Simple Multi-File Usage

To use basic compilation involving multiple files or object files, start with the following two source files:

one.c

#include <stdio.h>void hello(){  printf("Hello world!\n");}

two.c

extern void hello();int main(){  hello();  return 0;}

The following procedure illustrates a simple, multi-file compilation process in its most basic form.

Procedure 4.3. Compiling a Program with Multiple Source Files

Compile one.c into an executable with:
gcc -c one.c -o one.o
Ensure that the resulting binary one.o is in the same directory as one.c.
Compile two.c into an executable with:
gcc -c two.c -o two.o
Ensure that the resulting binary two.o is in the same directory as two.c.
Compile the two object files one.o and two.o into a single executable with:
gcc one.o two.o -o hello
Ensure that the resulting binary hello is in the same directory as one.o and two.o.
Run the hello binary, that is, hello.

4.1.6.4. Recommended Optimization Options

Different projects require different optimization options. There is no one-size-fits-all approach when it comes to optimization, but here are a few guidelines to keep in mind.

Instruction selection and tuning

It is very important to choose the correct architecture for instruction scheduling. By default GCC produces code optimized for the most common processors, but if the CPU on which your code will run is known, the corresponding -mtune= option to optimize the instruction scheduling, and -march= option to optimize the instruction selection should be used.

The option -mtune= optimizes instruction scheduling to fit your architecture by tuning everything except the ABI and the available instruction set. This option will not choose particular instructions, but instead will tune your program in such a way that executing on a particular architecture will be optimized. For example, if an Intel Core2 CPU will predominantly be used, choose -mtune=core2. If the wrong choice is made, the program will still run, but not optimally on the given architecture. The architecture on which the program will most likely run should always be chosen.

The option -march= optimizes instruction selection. As such, it is important to choose correctly as choosing incorrectly will cause your program to fail. This option selects the instruction set used when generating code. For example, if the program will be run on an AMD K8 core based CPU, choose -march=k8. Specifying the architecture with this option will imply -mtune=.

The -mtune= and -march= commands should only be used for tuning and selecting instructions within a given architecture, not to generate code for a different architecture (also known as cross-compiling). For example, this is not to be used to generate PowerPC code from an Intel 64 and AMD64 platform.

For a complete list of the available options for both -march= and -mtune=, refer to the GCC documentation available here: GCC 4.4.4 Manual: Hardware Models and Configurations

General purpose optimization flags

The compiler flag -O2 is a good middle of the road option to generate fast code. It produces the best optimized code when the resulting code size is not large. Use this when unsure what would best suit.

When code size is not an issue, -O3 is preferable. This option produces code that is slightly larger but runs faster because of a more frequent inline of functions. This is ideal for floating point intensive code.

The other general purpose optimization flag is -Os. This flag also optimizes for size, and produces faster code in situations where a smaller footprint will increase code locality, thereby reducing cache misses.

Use -frecord-gcc-switches when compiling objects. This records the options used to build objects into objects themselves. After an object is built, it determines which set of options were used to build it. The set of options are then recorded in a section called .GCC.command.line within the object and can be examined with the following:

$ gcc -frecord-gcc-switches -O3 -Wall hello.c -o hello$ readelf --string-dump=.GCC.command.line helloString dump of section '.GCC.command.line':  [ 0]  hello.c  [ 8]  -mtune=generic  [ 17]  -O3  [ 1b]  -Wall  [ 21]  -frecord-gcc-switches

It is very important to test and try different options with a representative data set. Often, different modules or objects can be compiled with different optimization flags in order to produce optimal results. Refer to Section 4.1.6.5, "Using Profile Feedback to Tune Optimization Heuristics" for additional optimization tuning.

4.1.6.5. Using Profile Feedback to Tune Optimization Heuristics

During the transformation of a typical set of source code into an executable, tens of hundreds of choices must be made about the importance of speed in one part of code over another, or code size as opposed to code speed. By default, these choices are made by the compiler using reasonable heuristics, tuned over time to produce the optimum runtime performance. However, GCC also has a way to teach the compiler to optimize executables for a specific machine in a specific production environment. This feature is called profile feedback.

Profile feedback is used to tune optimizations such as:

Inlining
Branch prediction
Instruction scheduling
Inter-procedural constant propagation
Determining of hot or cold functions

Profile feedback compiles a program first to generate a program that is run and analyzed and then a second time to optimize with the gathered data.

Procedure 4.4. Using Profile Feedback

The application must be instrumented to produce profiling information by compiling it with -fprofile-generate.
Run the application to accumulate and save the profiling information.
Recompile the application with -fprofile-use.

Step three will use the profile information gathered in step one to tune the compiler's heuristics while optimizing the code into a final executable.

Procedure 4.5. Compiling a Program with Profiling Feedback

Compile source.c to include profiling instrumentation:
gcc source.c -fprofile-generate -O2 -o executable
Run executable to gather profiling information:
./executable
Recompile and optimize source.c with profiling information gathered in step one:
gcc source.c -fprofile-use -O2 -o executable

Multiple data collection runs, as seen in step two, will accumulate data into the profiling file instead of replacing it. This allows the executable in step two to be run multiple times with additional representative data in order to collect even more information.

The executable must run with representative levels of both the machine being used and a respective data set large enough for the input required. This ensures optimal results are achieved.

By default, GCC will generate the profile data into the directory where step one was performed. To generate this information elsewhere, compile with -fprofile-dir=DIR where DIR is the preferred output directory.

Warning

The format of the compiler feedback data file changes between compiler versions. It is imperative that the program compilation is repeated with each version of the compiler.

4.1.6.6. Using 32-bit compilers on a 64-bit host

On a 64-bit host, GCC will build executables that can only run on 64-bit hosts. However, GCC can be used to build executables that will run both on 64-bit hosts and on 32-bit hosts.

To build 32-bit binaries on a 64-bit host, first install 32-bit versions of any supporting libraries the executable may require. This must at least include supporting libraries for glibc and libgcc, and libstdc++ if the program is a C++ program. On Intel 64 and AMD64, this can be done with:

yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686

There may be cases where it is useful to to install additional 32-bit libraries that a program may require. For example, if a program uses the db4-devel libraries to build, the 32-bit version of these libraries can be installed with:

yum install db4-devel.i686

Note

The .i686 suffix on the x86 platform (as opposed to x86-64) specifies a 32-bit version of the given package. For PowerPC architectures, the suffix is ppc (as opposed to ppc64).

After the 32-bit libraries have been installed, the -m32 option can be passed to the compiler and linker to produce 32-bit executables. Provided the supporting 32-bit libraries are installed on the 64-bit system, this executable will be able to run on both 32-bit systems and 64-bit systems.

Procedure 4.6. Compiling a 32-bit Program on a 64-bit Host

On a 64-bit system, compile hello.c into a 64-bit executable with:
gcc hello.c -o hello64

Ensure that the resulting executable is a 64-bit binary:

$ file hello64hello64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped$ ldd hello64linux-vdso.so.1 =>  (0x00007fff242dd000)libc.so.6 => /lib64/libc.so.6 (0x00007f0721514000)/lib64/ld-linux-x86-64.so.2 (0x00007f0721893000)

The command file on a 64-bit executable will include ELF 64-bit in its output, and ldd will list /lib64/libc.so.6 as the main C library linked.

On a 64-bit system, compile hello.c into a 32-bit executable with:
gcc -m32 hello.c -o hello32

Ensure that the resulting executable is a 32-bit binary:

$ file hello32hello32: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped$ ldd hello32linux-gate.so.1 =>  (0x007eb000)libc.so.6 => /lib/libc.so.6 (0x00b13000)/lib/ld-linux.so.2 (0x00cd7000)

The command file on a 32-bit executable will include ELF 32-bit in its output, and ldd will list /lib/libc.so.6 as the main C library linked.

If you have not installed the 32-bit supporting libraries you will get an error similar to this for C code:

$ gcc -m32 hello32.c -o hello32/usr/bin/ld: crt1.o: No such file: No such file or directorycollect2: ld returned 1 exit status

A similar error would be triggered on C++ code:

$ g++ -m32 hello32.cc -o hello32-c++In file included from /usr/include/features.h:385, from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-redhat-linux/32/bits/os_defines.h:39, from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-redhat-linux/32/bits/c++config.h:243, from /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/iostream:39, from hello32.cc:1:/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

These errors indicate that the supporting 32-bit libraries have not been properly installed as explained at the beginning of this section.

Also important is to note that building with -m32 will in not adapt or convert a program to resolve any issues arising from 32/64-bit incompatibilities. For tips on writing portable code and converting from 32-bits to 64-bits, see the paper entitled Porting to 64-bit GNU/Linux Systems in the Proceedings of the 2003 GCC Developers Summit.

4.1.7. GCC Documentation

For more information about GCC compilers, refer to the man pages for cpp, gcc, g++, gcj, and gfortran.

the following online user manuals are also available:

The main site for the development of GCC is gcc.gnu.org.

4.2. Distributed Compiling

Red Hat Enterprise Linux 6 also supports distributed compiling. This involves transforming one compile job into many smaller jobs; these jobs are distributed over a cluster of machines, which speeds up build time (particularly for programs with large codebases). The distcc package provides this capability.

To set up distributed compiling, install the following packages:

distcc
distcc-server

For more information about distributed compiling, refer to the man pages for distcc and distccd. The following link also provides detailed information about the development of distcc:

http://code.google.com/p/distcc

4.3. Autotools

GNU Autotools is a suite of command line tools that allow developers to build applications on different systems, regardless of the installed packages or even Linux distribution. These tools aid developers in creating a configure script. This script runs prior to builds and creates the top-level Makefiles required to build the application. The configure script may perform tests on the current system, create additional files, or run other directives as per parameters provided by the builder.

The Autotools suite's most commonly-used tools are:

autoconf: Generates the configure script from an input file (configure.ac, for example)
automake: Creates the Makefile for a project on a specific system
autoscan: Generates a preliminary input file (that is, configure.scan), which can be edited to create a final configure.ac to be used by autoconf

All tools in the Autotools suite are part of the Development Tools group package. You can install this package group to install the entire Autotools suite, or use yum to install any tools in the suite as you wish.

4.3.1. Autotools Plug-in for Eclipse

The Autotools suite is also integrated into the Eclipse IDE via the Autotools plug-in. This plug-in provides an Eclipse graphical user interface for Autotools, which is suitable for most C/C++ projects.

As of Red Hat Enterprise Linux 6, this plug-in only supports two templates for new C/C++ projects:

An empty project
A "hello world" application

The empty project template is used when importing projects into the C/C++ Development Toolkit that already support Autotools. Future updates to the Autotools plug-in will include additional graphical user interfaces (wizards, for example) for creating shared libraries and other complex scenarios.

The Red Hat Enterprise Linux 6 version of the Autotools plug-in also does not integrate git or mercurial into Eclipse. As such, Autotools projects that use git repositories will be required to be checked out outside the Eclipse workspace. Afterwards, you can specify the source location for such projects in Eclipse. Any repository manipulation (commits, or updates for example) are done via the command line.

4.3.2. Configuration Script

The most crucial function of Autotools is the creation of the configure script. This script tests systems for tools, input files, and other features it can use in order to build the project ^[2]. The configure script generates a Makefile which allows the make tool to build the project based on the system configuration.

To create the configure script, first create an input file. Then feed it to an Autotools utility in order to create the configure script. This input file is typically configure.ac or Makefile.am; the former is usually processed by autoconf, while the later is fed to automake.

If a Makefile.am input file is available, the automake utility creates a Makefile template (that is, Makefile. in), which may refer to information collected at configuration time. For example, the Makefile may have to link to a particular library if and only if that library is already installed. When the configure script runs, automake will use the Makefile. in templates to create a Makefile.

If a configure.ac file is available instead, then autoconf will automatically create the configure script based on the macros invoked by configure.ac. To create a preliminary configure.ac, use the autoscan utility and edit the file accordingly.

4.3.3. Autotools Documentation

Red Hat Enterprise Linux 6 includes man pages for autoconf, automake, autoscan and most tools included in the Autotools suite. In addition, the Autotools community provides extensive documentation on autoconf and automake on the following websites:

The following is an online book describing the use of Autotools. Although the above online documentation is the recommended and most up to date information on Autotools, this book is a good alternative and introduction.

http://sourceware.org/autobook/

For information on how to create Autotools input files, refer to:

The following upstream example also illustrates the use of Autotools in a simple hello program:

http://www.gnu.org/software/hello/manual/hello.html

The Autotools Plug-in For Eclipse whitepaper also provides more detail on the Red Hat Enterprise Linux 6 release of the Autotools plug-in. This whitepaper also includes a "by example" case study to walk you through a typical use-case for the plug-in. Refer to the following link for more information:

https://access.redhat.com/sites/default/files/red_hat_enterprise_linux-6-autotools_plug-in_for_eclipse-en-us.pdf

4.4. Eclipse Built-in Specfile Editor

The Specfile Editor Plug-in for Eclipse provides useful features to help developers manage .spec files. This plug-in allows users to leverage several Eclipse GUI features in editing .spec files, such as auto-completion, highlighting, file hyperlinks, and folding.

In addition, the Specfile Editor Plug-in also integrates the rpmlint tool into the Eclipse interface. rpmlint is a command line tool that helps developers detect common RPM package errors. The richer visualization offered by the Eclipse interface helps developers quickly detect, view, and correct mistakes reported by rpmlint.

The Specfile Editor for Eclipse is provided by the eclipse-rpm-editor package. For more information about this plug-in, refer to Specfile Editor User Guide in the Eclipse Help Contents.

4.5. CDT in Eclipse

The CDT (C/C++ Development Tools) is an Eclipse project that adds support for developing C and C++ projects with Eclipse. A user can create three forms of projects:

Managed Make Project
Standard Make Project
Autotools Project

4.5.1. Managed Make Project

A managed make CDT project, sometimes referred to as a managed project, is one where the details regarding how to build the project are automated on behalf of the end-user. This differs from the standard make project, another common type of CDT C/C++ project, whereby a user supplies a Makefile that has the build details specified.

For a managed project, start by selecting the type of managed project and the required toolchain. The project type is categorized based on the ultimate target of the project, such as an executable, a shared library, or a static library. Within these categories there may be templates for more specific projects (a hello world sample executable project, for example) where base source files are already provided. These can then be further customized.

A toolchain is the set of tools used to generate the target. Typically, a Red Hat Enterprise Linux C/C++ developer would select the Linux GCC toolchain, which uses GCC for compiling, linking and assembly. Each tool in the toolchain is associated with one or more input types, typically specified by file suffix (for example, .c or .h or .S) or by file name. The tool will have parameter settings which can be customized by the developer, and each tool has an output type it creates. The tool also has a command or binary executable associated with it which may overlap among multiple tools. The C compiler and linker, for example, can both use GCC, but the compiler and linker tools will each have different input and output types, as well as different settings presented to the developer. Customize the tool settings through Properties > C/C++ Build > Settings. The toolchain itself can be customized in order to add, remove, or replace the used tools through Properties > C/C++ Build > Toolchain Editor.

New files, such as source files or header files, can be added to the project once it has been created. The new files are added automatically to the build based on their input types and the tool settings. Navigate to Project > C/C++ Build under the Builder Settings tab in order for the managed make project to generate a Makefile which can be distributed with the project. This facilitates the use of the Makefile outside Eclipse.

For more information regarding managed make C/C++ projects, refer to the C/C++ Development User Guide which can be found by navigating to Concepts > Project Types, Tasks > Creating a Project, or Reference > C/C++ Properties > C/C++ Project Properties > C/C++ Build > Settings Page.

4.5.2. Standard Make Project

A standard make CDT project is a traditional C project with a Makefile that is manually managed by the developer. Unlike the managed make project, there are no tool settings to be used in determining rules in the Makefile. Manual additions to the Makefile are required when new source files that are to be processed as part of the build are added to the project. If a pattern rule exists which the new file name matches (for example, .c:.o, which states how to process a file with the suffix .c into a file with the suffix .o), then this is not required.

The default make target for building the project is all, and the default make target for cleaning the project is clean. It is also possible for a user to build other targets found in the Makefile. To do this use the Makefile Target dialog to create targets to run or build existing ones. Creating pseudo-targets that group multiple targets found in the makefile in a particular order is also done through the Makefile Target dialog. To access the specific create and build dialogs, select Project > Make Target > Create... and Project > Make Target > Build... respectively. Alternatively, right click on resources in the project and select the Make Targets option to access either Create... or Build...

For more information regarding standard make C/C++ projects, refer to the C/C++ Development user guide, accessed through Concepts > Project Types, Tasks > Creating a project or Reference > C/C++ Properties > C/C++ Project Properties > C/C++Build > Settings Page.

4.5.3. Autotools Project

An autotools project is a lot like a standard make project however the Makefile is usually generated as part of a configuration step that occurs prior to building. See Section 4.3, "Autotools" for details on Autotools and the Autotools plug-in for Eclipse which adds support for this type of project. Like a standard make project, make targets can be run with the Make Target dialog.

4.6. build-id Unique Identification of Binaries

Each executable or shared library built with Red Hat Enterprise Linux Server 6 or later is assigned a unique identification 160-bit SHA-1 string, generated as a checksum of selected parts of the binary. This allows two builds of the same program on the same host to always produce consistent build-ids and binary content.

Display the build-id of a binary with the following command:

$ eu-readelf -n /bin/bash[...]Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x274:  OwnerData size Type  GNU   20 GNU_BUILD_ID Build ID: efdd0b5e69b0742fa5e5bad0771df4d1df2459d1

Unique identificators of binaries are useful in cases such as analysing core files, documented Section 5.2.1, "Installing Debuginfo Packages for Core Files Analysis".

4.7. Software Collections and `scl-utils`

With Software Collections, it is possible to build and concurrently install multiple versions of the same RPM packages on a system. Software Collections have no impact on the system versions of the packages installed by the conventional RPM package manager.

To enable support for Software Collections on a system, install the packages scl-utils and scl-utils-build by typing the following at a shell prompt:

# yum install -y scl-utils scl-utils-build

The scl-utils package provides the scl tool which is used to enable a Software Collection and to run applications in the Software Collection environment.

General usage of the scl tool can be described using the following syntax:

 scl action software_collection_1 software_collection_2 command

Example 4.1. Running an Application Directly

To directly run Perl with the --version option in the Software Collection named software_collection_1, execute the following command:

 scl enable software_collection_1 'perl --version'

Example 4.2. Running a Shell with Multiple Software Collections Enabled

To run the Bash shell in the environment with multiple Software Collections enabled, execute the following command:

 scl enable software_collection_1 software_collection_2 bash

The command above enables two Software Collections named software_collection_1 and software_collection_2.

Example 4.3. Running Commands Stored in a File

To execute a number of commands, which are stored in a file, in the Software Collection environment, run the following command:

 cat cmd | scl enable software_collection_1 -

The command above executes commands, which are stored in the cmd file, in the environment of the Software Collection named software_collection_1.

For more information regarding Software Collections and scl-utils, refer to the Software Collections Guide as part of the Red Hat Developer Toolset.

^[2]For information about tests that configure can perform, refer to the following link:

http://www.gnu.org/software/autoconf/manual/autoconf.html#Existing-Tests

Developer Guide

Chapter 4. Compiling and Building

4.1. GNU Compiler Collection (GCC)

4.1.1. GCC Status and Features

4.1.2. Language Compatibility

4.1.3. Object Compatibility and Interoperability

4.1.4. Backwards Compatibility Packages

4.1.5. Previewing Red Hat Enterprise Linux 6 compiler features on Red Hat Enterprise Linux 5

4.1.6. Running GCC

4.1.6.1. Simple C Usage

4.1.6.2. Simple C++ Usage

4.1.6.3. Simple Multi-File Usage

4.1.6.4. Recommended Optimization Options

4.1.6.5. Using Profile Feedback to Tune Optimization Heuristics

4.1.6.6. Using 32-bit compilers on a 64-bit host

4.1.7. GCC Documentation

4.2. Distributed Compiling

4.3. Autotools

4.3.1. Autotools Plug-in for Eclipse

4.3.2. Configuration Script

4.3.3. Autotools Documentation

4.4. Eclipse Built-in Specfile Editor

4.5. CDT in Eclipse

4.5.1. Managed Make Project

4.5.2. Standard Make Project

4.5.3. Autotools Project

4.6. build-id Unique Identification of Binaries

4.7. Software Collections and scl-utils

4.7. Software Collections and `scl-utils`