Porting and Maintenance

Table of Contents

Configure and Build Hacking
Prerequisites
Overview: What Comes from Where
Storing Information in non-AC files (like configure.host)
Coding and Commenting Conventions
The acinclude.m4 layout
GLIBCXX_ENABLE, the --enable maker
Writing and Generating Documentation
Introduction
Generating Documentation
Doxygen
Prerequisites
Generating the Doxygen Files
Markup
Docbook
Prerequisites
Generating the DocBook Files
Editing and Validation
File Organization and Basics
Markup By Example
Porting to New Hardware or Operating Systems
Operating System
CPU
Character Types
Thread Safety
Numeric Limits
Libtool
Test
Organization
Directory Layout
Naming Conventions
Running the Testsuite
Basic
Variations
Permutations
Writing a new test case
Test Harness and Utilities
Dejagnu Harness Details
Utilities
Special Topics
Qualifying Exception Safety Guarantees
Overview
Existing tests
C++11 Requirements Test Sequence Descriptions
ABI Policy and Guidelines
The C++ Interface
Versioning
Goals
History
Prerequisites
Configuring
Checking Active
Allowed Changes
Prohibited Changes
Implementation
Testing
Single ABI Testing
Multiple ABI Testing
Outstanding Issues
API Evolution and Deprecation History
3.0
3.1
3.2
3.3
3.4
4.0
4.1
4.2
4.3
4.4
4.5
Backwards Compatibility
First
No ios_base
No cout in <ostream.h>, no cin in <istream.h>
Second
Namespace std:: not supported
Illegal iterator usage
isspace from <cctype> is a macro
No vector::at, deque::at, string::at
No std::char_traits<char>::eof
No string::clear
Removal of ostream::form and istream::scan extensions
No basic_stringbuf, basic_stringstream
Little or no wide character support
No templatized iostreams
Thread safety issues
Third
Pre-ISO headers moved to backwards or removed
Extension headers hash_map, hash_set moved to ext or backwards
No ios::nocreate/ios::noreplace.
No stream::attach(int fd)
Support for C++98 dialect.
Support for C++TR1 dialect.
Support for C++11 dialect.
Container::iterator_type is not necessarily Container::value_type*

As noted previously, certain other tools are necessary for hacking on files that control configure (configure.ac, acinclude.m4) and make (Makefile.am). These additional tools (automake, and autoconf) are further described in detail in their respective manuals. All the libraries in GCC try to stay in sync with each other in terms of versions of the auto-tools used, so please try to play nicely with the neighbors.

The nice thing about acinclude.m4/aclocal.m4 is that macros aren't actually performed/called/expanded/whatever here, just loaded. So we can arrange the contents however we like. As of this writing, acinclude.m4 is arranged as follows:

    GLIBCXX_CHECK_HOST
    GLIBCXX_TOPREL_CONFIGURE
    GLIBCXX_CONFIGURE
  

All the major variable "discovery" is done here. CXX, multilibs, etc.

    fragments included from elsewhere
  

Right now, "fragments" == "the math/linkage bits".

    GLIBCXX_CHECK_COMPILER_FEATURES
    GLIBCXX_CHECK_LINKER_FEATURES
    GLIBCXX_CHECK_WCHAR_T_SUPPORT

Next come extra compiler/linker feature tests. Wide character support was placed here because I couldn't think of another place for it. It will probably get broken apart like the math tests, because we're still disabling wchars on systems which could actually support them.

    GLIBCXX_CHECK_SETRLIMIT_ancilliary
    GLIBCXX_CHECK_SETRLIMIT
    GLIBCXX_CHECK_S_ISREG_OR_S_IFREG
    GLIBCXX_CHECK_POLL
    GLIBCXX_CHECK_WRITEV

    GLIBCXX_CONFIGURE_TESTSUITE

Feature tests which only get used in one place. Here, things used only in the testsuite, plus a couple bits used in the guts of I/O.

    GLIBCXX_EXPORT_INCLUDES
    GLIBCXX_EXPORT_FLAGS
    GLIBCXX_EXPORT_INSTALL_INFO

Installation variables, multilibs, working with the rest of the compiler. Many of the critical variables used in the makefiles are set here.

    GLIBGCC_ENABLE
    GLIBCXX_ENABLE_C99
    GLIBCXX_ENABLE_CHEADERS
    GLIBCXX_ENABLE_CLOCALE
    GLIBCXX_ENABLE_CONCEPT_CHECKS
    GLIBCXX_ENABLE_CSTDIO
    GLIBCXX_ENABLE_CXX_FLAGS
    GLIBCXX_ENABLE_C_MBCHAR
    GLIBCXX_ENABLE_DEBUG
    GLIBCXX_ENABLE_DEBUG_FLAGS
    GLIBCXX_ENABLE_LONG_LONG
    GLIBCXX_ENABLE_PCH
    GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
    GLIBCXX_ENABLE_SYMVERS
    GLIBCXX_ENABLE_THREADS

All the features which can be controlled with enable/disable configure options. Note how they're alphabetized now? Keep them like that. :-)

    AC_LC_MESSAGES
    libtool bits

Things which we don't seem to use directly, but just has to be present otherwise stuff magically goes wonky.

All the GLIBCXX_ENABLE_FOO macros use a common helper, GLIBCXX_ENABLE. (You don't have to use it, but it's easy.) The helper does two things for us:

Doing these things correctly takes some extra autoconf/autom4te code, which made our macros nearly illegible. So all the ugliness is factored out into this one helper macro.

Many of the macros take an argument, passed from when they are expanded in configure.ac. The argument controls the default value of the enable/disable switch. Previously, the arguments themselves had defaults. Now they don't, because that's extra complexity with zero gain for us.

There are three "overloaded signatures". When reading the descriptions below, keep in mind that the brackets are autoconf's quotation characters, and that they will be stripped. Examples of just about everything occur in acinclude.m4, if you want to look.

    GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING)
    GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c)
    GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER)

With no other arguments, only the standard autoconf patterns are allowed: "--{enable,disable}-foo[={yes,no}]" The $enable_FEATURE variable is guaranteed to equal either "yes" or "no" after the macro. If the user tries to pass something else, an explanatory error message will be given, and configure will halt.

The second signature takes a fifth argument, "[permit a | b | c | ...]" This allows a or b or ... after the equals sign in the option, and $enable_FEATURE is guaranteed to equal one of them after the macro. Note that if you want to allow plain --enable/--disable with no "=whatever", you must include "yes" and "no" in the list of permitted values. Also note that whatever you passed as DEFAULT must be in the list. If the user tries to pass something not on the list, a semi-explanatory error message will be given, and configure will halt. Example: [permit generic|gnu|ieee_1003.1-2001|yes|no|auto]

The third signature takes a fifth argument. It is arbitrary shell code to execute if the user actually passes the enable/disable option. (If the user does not, the default is used. Duh.) No argument checking at all is done in this signature. See GLIBCXX_ENABLE_CXX_FLAGS for an example of handling, and an error message.