aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/docs/html/17_intro
diff options
context:
space:
mode:
Diffstat (limited to 'libstdc++-v3/docs/html/17_intro')
-rw-r--r--libstdc++-v3/docs/html/17_intro/confdeps.dot14
-rw-r--r--libstdc++-v3/docs/html/17_intro/confdeps.pngbin0 -> 3486 bytes
-rw-r--r--libstdc++-v3/docs/html/17_intro/configury.html285
-rw-r--r--libstdc++-v3/docs/html/17_intro/headers_cc.txt2
-rw-r--r--libstdc++-v3/docs/html/17_intro/howto.html8
-rw-r--r--libstdc++-v3/docs/html/17_intro/porting.html90
-rw-r--r--libstdc++-v3/docs/html/17_intro/porting.texi2
7 files changed, 355 insertions, 46 deletions
diff --git a/libstdc++-v3/docs/html/17_intro/confdeps.dot b/libstdc++-v3/docs/html/17_intro/confdeps.dot
new file mode 100644
index 00000000000..a62d28ce9dd
--- /dev/null
+++ b/libstdc++-v3/docs/html/17_intro/confdeps.dot
@@ -0,0 +1,14 @@
+# Blatantly ripped out of the graphviz examples and modified. -pme
+digraph v3conf {
+ size="6,6";
+ node [color=lightblue2, style=filled];
+ "aclocal.m4" -> "acinclude.m4";
+ "configure" -> "aclocal.m4";
+ "configure" -> "configure.ac";
+ "configure" -> "crossconfig.m4";
+ "configure" -> "linkage.m4";
+ "[*/]Makefile.in" -> "Makefile.am";
+ "[*/]Makefile.in" -> "configure.ac";
+ "config.h.in" -> "acconfig.h";
+ "config.h.in" -> "configure.ac";
+}
diff --git a/libstdc++-v3/docs/html/17_intro/confdeps.png b/libstdc++-v3/docs/html/17_intro/confdeps.png
new file mode 100644
index 00000000000..5075aa869b1
--- /dev/null
+++ b/libstdc++-v3/docs/html/17_intro/confdeps.png
Binary files differ
diff --git a/libstdc++-v3/docs/html/17_intro/configury.html b/libstdc++-v3/docs/html/17_intro/configury.html
new file mode 100644
index 00000000000..8b44ff381dc
--- /dev/null
+++ b/libstdc++-v3/docs/html/17_intro/configury.html
@@ -0,0 +1,285 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+ <meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
+ <meta name="DESCRIPTION" content="configury for libstdc++" />
+ <meta name="GENERATOR" content="vi and eight fingers" />
+ <title>libstdc++-v3 configury</title>
+<link rel="StyleSheet" href="../lib3styles.css" />
+</head>
+<body>
+
+<h1><code>&gt; open configury door</code></h1>
+<h1><code>&gt; look</code></h1>
+
+<p class="larger"><code>You are in a maze of twisty passages, all
+different.</code></p>
+<p class="larger"><code>It is dark. You are likely to be eaten by a
+Canadian cross build.</code></p>
+
+
+<hr />
+<h2>Notes on libstdc++-v3 configury</h2>
+<blockquote>
+No problem is insoluble in all conceivable circumstances.<br />
+-- The Cosmic AC,
+<a href="http://people.inf.elte.hu/simi/szovegek/Asimov1.html">The
+Last Question</a>, by Isaac Asimov
+</blockquote>
+<ul>
+ <li><a href="#deps">what comes from where</a></li>
+ <li><a href="#breakout">storing information in non-AC files, like
+ configure.host</a></li>
+ <li><a href="#general">general config notes</a></li>
+ <li><a href="#aclayout">acinclude.m4 layout</a></li>
+ <li><a href="#enable"><code>--enable</code> howto</a></li>
+</ul>
+
+<hr />
+<h3><a name="deps">what comes from where</a></h3>
+<p class="centered"><img src="confdeps.png"
+ alt="Dependency graph in PNG graphics format. (Get a better browser!)"></p>
+
+<p>Regenerate using a command sequence like
+ <code>"aclocal-1.7 &amp;&amp; autoconf2.50 &amp;&amp; autoheader2.50
+ &amp;&amp; automake-1.7"</code> as needed. And/or configure with
+ --enable-maintainer-mode.
+</p>
+
+
+<hr />
+<h3><a name="breakout">storing information in non-AC files, like
+ configure.host</a></h3>
+<p>Until that glorious day when we can use AC_TRY_LINK with a cross-compiler,
+ we have to hardcode the results of what the tests would have shown if
+ they could be run. So we have an inflexible mess like crossconfig.m4.
+</p>
+
+<p>Wouldn't it be nice if we could store that information in files like
+ configure.host, which can be modified without needing to regenerate
+ anything, and can even be tweaked without really knowing how the configury
+ all works? Perhaps break the pieces of crossconfig.m4 out and place them in
+ their appropriate config/{cpu,os} directory.
+</p>
+
+<p>Alas, writing macros like "<code>AC_DEFINE(HAVE_A_NICE_DAY)</code>" can
+ only be done inside files which are passed through autoconf. Files which
+ are pure shell script can be source'd at configure time. Files which
+ contain autoconf macros must be processed with autoconf. We could still
+ try breaking the pieces out into "config/*/cross.m4" bits, for instance,
+ but then we would need arguments to aclocal/autoconf to properly find
+ them all when generating configure. I would discourage that.
+</p>
+
+
+<hr />
+<h3><a name="general">general config notes</a></h3>
+<p>Lots of stuff got thrown out because the new autotools kindly generate
+ the same (or better) shell code for us.
+</p>
+
+<p>Most comments should use {octothorpes, shibboleths, hash marks, pound
+ signs, whatevers} rather than "dnl". Nearly all comments in configure.ac
+ should. Comments inside macros written in ancilliary .m4 files should.
+ About the only comments which should <em>not</em> use #, but use dnl
+ instead, are comments <em>outside</em> our own macros in the ancilliary
+ files. The difference is that # comments show up in <code>configure</code>
+ (which is most helpful for debugging), while dnl'd lines just vanish.
+ Since the macros in ancilliary files generate code which appears in odd
+ places, their "outside" comments tend to not be useful while reading
+ <code>configure</code>.
+</p>
+
+<p>Do not use any <code>$target*</code> variables, such as
+ <code>$target_alias</code>. The single exception is in configure.ac,
+ for automake+dejagnu's sake.
+</p>
+
+<p>
+</p>
+
+<hr />
+<h3><a name="aclayout">acinclude.m4 layout</a></h3>
+<p>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:
+</p>
+<pre>
+ GLIBCXX_CHECK_HOST
+ GLIBCXX_TOPREL_CONFIGURE
+ GLIBCXX_CONFIGURE
+</pre>
+<p>All the major variable "discovery" is done here. CXX, multilibs, etc.
+</p>
+<pre>
+ fragments included from elsewhere
+</pre>
+<p>Right now, "fragments" == "the math/linkage bits".
+</p>
+<pre>
+ GLIBCXX_CHECK_COMPILER_FEATURES
+ GLIBCXX_CHECK_LINKER_FEATURES
+ GLIBCXX_CHECK_WCHAR_T_SUPPORT
+</pre>
+<p>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.
+</p>
+<pre>
+ GLIBCXX_CHECK_SETRLIMIT_ancilliary
+ GLIBCXX_CHECK_SETRLIMIT
+ GLIBCXX_CHECK_S_ISREG_OR_S_IFREG
+ GLIBCXX_CHECK_POLL
+ GLIBCXX_CHECK_WRITEV
+
+ GLIBCXX_CONFIGURE_TESTSUITE
+</pre>
+<p>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.
+</p>
+<pre>
+ GLIBCXX_EXPORT_INCLUDES
+ GLIBCXX_EXPORT_FLAGS
+ GLIBCXX_EXPORT_INSTALL_INFO
+</pre>
+<p>Installation variables, multilibs, working with the rest of the compiler.
+ Many of the critical variables used in the makefiles are set here.
+</p>
+<pre>
+ 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_LIBUNWIND_EXCEPTIONS
+ GLIBCXX_ENABLE_LONG_LONG
+ GLIBCXX_ENABLE_PCH
+ GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
+ GLIBCXX_ENABLE_SYMVERS
+ GLIBCXX_ENABLE_THREADS
+</pre>
+<p>All the features which can be controlled with enable/disable configure
+ options. Note how they're alphabetized now? Keep them like that. :-)
+</p>
+<pre>
+ AC_LC_MESSAGES
+ libtool bits
+</pre>
+<p>Things which we don't seem to use directly, but just has to be present
+ otherwise stuff magically goes wonky.
+</p>
+
+
+<hr />
+<h3><a name="enable"><code>--enable</code> howto</a></h3>
+<p>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:
+</p>
+
+<ol>
+ <li>Builds the call to the AC_ARG_ENABLE macro, with --help text properly
+ quoted and aligned. (Death to changequote!)</li>
+ <li>Checks the result against a list of allowed possibilities, and signals
+ a fatal error if there's no match. This means that the rest of the
+ GLIBCXX_ENABLE_FOO macro doesn't need to test for strange arguments,
+ nor do we need to protect against empty/whitespace strings with the
+ <code>"x$foo" = "xbar"</code> idiom.</li>
+</ol>
+
+<p>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.
+</p>
+
+<p>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.
+</p>
+
+<p>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.
+</p>
+
+<pre>
+ 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)
+</pre>
+
+<ul>
+ <li><p>FEATURE is the string that follows --enable. The results of the test
+ (such as it is) will be in the variable $enable_FEATURE, where FEATURE
+ has been squashed. Example: <code>[extra-foo]</code>, controlled by the
+ --enable-extra-foo option and stored in $enable_extra_foo.</p></li>
+ <li><p>DEFAULT is the value to store in $enable_FEATURE if the user does not
+ pass --enable/--disable. It should be one of the permitted values
+ passed later. Examples: <code>[yes]</code>, or <code>[bar]</code>, or
+ <code>[$1]</code> (which passes the argument given to the
+ GLIBCXX_ENABLE_FOO macro as the default).</p>
+ <p>For cases where we need to probe for particular models
+ of things, it is useful to have an undocumented "auto" value here (see
+ GLIBCXX_ENABLE_CLOCALE for an example).</p></li>
+ <li><p>HELP-ARG is any text to append to the option string itself in the
+ --help output. Examples: <code>[]</code> (i.e., an empty string,
+ which appends nothing),
+ <code>[=BAR]</code>, which produces
+ <code>--enable-extra-foo=BAR</code>, and
+ <code>[@&lt;:@=BAR@:&gt;@]</code>, which produces
+ <code>--enable-extra-foo[=BAR]</code>. See the difference? See what
+ it implies to the user?</p>
+ <p>If you're wondering what that line noise in the last example was,
+ that's how you embed autoconf special characters in output text.
+ They're called
+<a href="http://www.gnu.org/manual/autoconf/html_node/autoconf_95.html#SEC95"><em>quadrigraphs</em></a>
+ and you should use them whenever necessary.</p></li>
+ <li><p>HELP-STRING is what you think it is. Do not include the "default"
+ text like we used to do; it will be done for you by GLIBCXX_ENABLE.
+ By convention, these are not full English sentences.
+ Example: [turn on extra foo]</p></li>
+</ul>
+
+<p>With no other arguments, only the standard autoconf patterns are
+ allowed: "<code>--{enable,disable}-foo[={yes,no}]</code>" 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.
+</p>
+
+<p>The second signature takes a fifth argument,
+ "<code>[permit <em>a</em>|<em>b</em>|<em>c</em>|<em>...</em>]</code>"
+ This allows <em>a</em> or <em>b</em> 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: <code>[permit generic|gnu|ieee_1003.1-2001|yes|no|auto]</code>
+</p>
+
+<p>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.
+</p>
+
+<hr />
+</body>
+</html>
diff --git a/libstdc++-v3/docs/html/17_intro/headers_cc.txt b/libstdc++-v3/docs/html/17_intro/headers_cc.txt
index eb930f1ff00..667f2fe235b 100644
--- a/libstdc++-v3/docs/html/17_intro/headers_cc.txt
+++ b/libstdc++-v3/docs/html/17_intro/headers_cc.txt
@@ -75,7 +75,7 @@
// "C" headers that might not work if wchar_t support is disabled.
#include <bits/c++config.h>
-#if _GLIBCPP_USE_WCHAR_T
+#if _GLIBCXX_USE_WCHAR_T
#include <cwchar>
#include <cwctype>
#endif
diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html
index fc43d0f5892..d1fc584679d 100644
--- a/libstdc++-v3/docs/html/17_intro/howto.html
+++ b/libstdc++-v3/docs/html/17_intro/howto.html
@@ -291,7 +291,8 @@
<a href="../configopts.html">the configuration step</a>, with the
various --enable/--disable choices being translated to #define/#undef).
</p>
- <p>All library macros begin with <code>_GLIBCPP_</code>. The fact that
+ <p>All library macros begin with <code>_GLIBCPP_</code> in earlier
+ versions, and <code>_GLIBCXX_</code> in later versions. The fact that
these symbols start with a leading underscore should give you a clue
that (by default) they aren't meant to be changed by the user. :-)
</p>
@@ -310,9 +311,10 @@
The default state of the symbol is listed. &quot;Configurable&quot;
(or &quot;Not configurable&quot;) means that the symbol is initially
chosen (or not) based on --enable/--disable options at configure time.
+ For 3.1 through 3.3, the prefixes are <code>_GLIBCPP_</code>.
</p>
<dl>
- <dt><code>_GLIBCPP_DEPRECATED</code></dt>
+ <dt><code>_GLIBCXX_DEPRECATED</code></dt>
<dd>Undefined by default. Not configurable. Turning this on enables
older ARM-style iostreams code, and other anachronisms. This may be
useful in updating old C++ programs which no longer meet the
@@ -331,7 +333,7 @@
you might try undefining this macro.
</dd>
-->
- <dt><code>_GLIBCPP_CONCEPT_CHECKS</code></dt>
+ <dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt>
<dd>Undefined by default. Configurable. When defined, performs
compile-time checking on certain template instantiations to detect
violations of the requirements of the standard. This is described
diff --git a/libstdc++-v3/docs/html/17_intro/porting.html b/libstdc++-v3/docs/html/17_intro/porting.html
index fb4682c8c2c..b0275592d30 100644
--- a/libstdc++-v3/docs/html/17_intro/porting.html
+++ b/libstdc++-v3/docs/html/17_intro/porting.html
@@ -3,8 +3,7 @@
<title>Porting libstdc++-v3</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Porting libstdc++-v3">
-<meta name="generator" content="makeinfo 4.3">
-<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
+<meta name="generator" content="makeinfo 4.6">
<!--
Copyright &copy; 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
@@ -25,20 +24,29 @@ texts being (a) (see below), and with the Back-Cover Texts being (b)
<p>You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.-->
+<meta http-equiv="Content-Style-Type" content="text/css">
+<style type="text/css"><!--
+ pre.display { font-family:inherit }
+ pre.format { font-family:inherit }
+ pre.smalldisplay { font-family:inherit; font-size:smaller }
+ pre.smallformat { font-family:inherit; font-size:smaller }
+ pre.smallexample { font-size:smaller }
+ pre.smalllisp { font-size:smaller }
+--></style>
</head>
<body>
<h1 class="settitle">Porting libstdc++-v3</h1>
<div class="node">
<p><hr>
-Node:<a name="Top">Top</a>,
-Next:<a rel="next" accesskey="n" href="#Operating%20system">Operating system</a>,
-Up:<a rel="up" accesskey="u" href="#dir">(dir)</a>
+Node:&nbsp;<a name="Top">Top</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#Operating%20system">Operating system</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#dir">(dir)</a>
<br>
</div>
<h2 class="unnumbered">Porting libstdc++-v3</h2>
- <p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
+<p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
a new target.
<p>In order to make the GNU C++ library (libstdc++-v3) work with a new
@@ -57,7 +65,7 @@ works. It is difficult to test the C++ compiler without a working
library, but you should at least try some minimal test cases.
<p>(Note that what we think of as a "target," the library refers to as
-a "host." The comment at the top of <code>configure.in</code> explains why.)
+a "host." The comment at the top of <code>configure.ac</code> explains why.)
<p>Here are the primary steps required to port the library:
@@ -73,16 +81,16 @@ a "host." The comment at the top of <code>configure.in</code> explains why.)
<div class="node">
<p><hr>
-Node:<a name="Operating%20system">Operating system</a>,
-Next:<a rel="next" accesskey="n" href="#CPU">CPU</a>,
-Previous:<a rel="previous" accesskey="p" href="#Top">Top</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="Operating%20system">Operating system</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#CPU">CPU</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Top">Top</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">Operating system</h2>
- <p>If you are porting to a new operating system (as opposed to a new chip
+<p>If you are porting to a new operating system (as opposed to a new chip
using an existing operating system), you will need to create a new
directory in the <code>config/os</code> hierarchy. For example, the IRIX
configuration files are all in <code>config/os/irix</code>. There is no set
@@ -191,16 +199,16 @@ starting point.
<div class="node">
<p><hr>
-Node:<a name="CPU">CPU</a>,
-Next:<a rel="next" accesskey="n" href="#Character%20types">Character types</a>,
-Previous:<a rel="previous" accesskey="p" href="#Operating%20system">Operating system</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="CPU">CPU</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#Character%20types">Character types</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Operating%20system">Operating system</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">CPU</h2>
- <p>If you are porting to a new chip (as opposed to a new operating system
+<p>If you are porting to a new chip (as opposed to a new operating system
running on an existing chip), you will need to create a new directory in the
<code>config/cpu</code> hierarchy. Much like the <a href="#Operating%20system">Operating system</a> setup,
there are no strict rules on how to organize the CPU configuration
@@ -224,16 +232,16 @@ appropriate for your chip.
<div class="node">
<p><hr>
-Node:<a name="Character%20types">Character types</a>,
-Next:<a rel="next" accesskey="n" href="#Thread%20safety">Thread safety</a>,
-Previous:<a rel="previous" accesskey="p" href="#CPU">CPU</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="Character%20types">Character types</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#Thread%20safety">Thread safety</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#CPU">CPU</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">Character types</h2>
- <p>The library requires that you provide three header files to implement
+<p>The library requires that you provide three header files to implement
character classification, analogous to that provided by the C libraries
<code>&lt;ctype.h&gt;</code> header. You can model these on the files provided in
<code>config/os/generic</code>. However, these files will almost
@@ -421,16 +429,16 @@ from <code>__low</code> up until <code>__high</code> into the vector given by
<div class="node">
<p><hr>
-Node:<a name="Thread%20safety">Thread safety</a>,
-Next:<a rel="next" accesskey="n" href="#Numeric%20limits">Numeric limits</a>,
-Previous:<a rel="previous" accesskey="p" href="#Character%20types">Character types</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="Thread%20safety">Thread safety</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#Numeric%20limits">Numeric limits</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Character%20types">Character types</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">Thread safety</h2>
- <p>The C++ library string functionality requires a couple of atomic
+<p>The C++ library string functionality requires a couple of atomic
operations to provide thread-safety. If you don't take any special
action, the library will use stub versions of these functions that are
not thread-safe. They will work fine, unless your applications are
@@ -498,16 +506,16 @@ must be equivalent to those provided here, but using atomic operations:
<div class="node">
<p><hr>
-Node:<a name="Numeric%20limits">Numeric limits</a>,
-Next:<a rel="next" accesskey="n" href="#Libtool">Libtool</a>,
-Previous:<a rel="previous" accesskey="p" href="#Thread%20safety">Thread safety</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="Numeric%20limits">Numeric limits</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#Libtool">Libtool</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Thread%20safety">Thread safety</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">Numeric limits</h2>
- <p>The C++ library requires information about the fundamental data types,
+<p>The C++ library requires information about the fundamental data types,
such as the minimum and maximum representable values of each type.
You can define each of these values individually, but it is usually
easiest just to indicate how many bits are used in each of the data
@@ -523,16 +531,16 @@ your CPU configuration directory (see <a href="#CPU">CPU</a>).
<div class="node">
<p><hr>
-Node:<a name="Libtool">Libtool</a>,
-Next:<a rel="next" accesskey="n" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel="previous" accesskey="p" href="#Numeric%20limits">Numeric limits</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="Libtool">Libtool</a>,
+Next:&nbsp;<a rel="next" accesskey="n" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Numeric%20limits">Numeric limits</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
<h2 class="chapter">Libtool</h2>
- <p>The C++ library is compiled, archived and linked with libtool.
+<p>The C++ library is compiled, archived and linked with libtool.
Explaining the full workings of libtool is beyond the scope of this
document, but there are a few, particular bits that are necessary for
porting.
@@ -561,9 +569,9 @@ operating system.
<div class="node">
<p><hr>
-Node:<a name="GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel="previous" accesskey="p" href="#Libtool">Libtool</a>,
-Up:<a rel="up" accesskey="u" href="#Top">Top</a>
+Node:&nbsp;<a name="GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
+Previous:&nbsp;<a rel="previous" accesskey="p" href="#Libtool">Libtool</a>,
+Up:&nbsp;<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
</div>
@@ -947,7 +955,7 @@ as a draft) by the Free Software Foundation.
<h3 class="unnumberedsec">ADDENDUM: How to use this License for your documents</h3>
- <p>To use this License in a document you have written, include a copy of
+<p>To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:
diff --git a/libstdc++-v3/docs/html/17_intro/porting.texi b/libstdc++-v3/docs/html/17_intro/porting.texi
index ed4042f932d..988c2c2203a 100644
--- a/libstdc++-v3/docs/html/17_intro/porting.texi
+++ b/libstdc++-v3/docs/html/17_intro/porting.texi
@@ -75,7 +75,7 @@ works. It is difficult to test the C++ compiler without a working
library, but you should at least try some minimal test cases.
(Note that what we think of as a ``target,'' the library refers to as
-a ``host.'' The comment at the top of @file{configure.in} explains why.)
+a ``host.'' The comment at the top of @file{configure.ac} explains why.)
Here are the primary steps required to port the library: