-<html>
+<?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="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" />
<h1 class="centered">libstdc++ Frequently Asked Questions</h1>
-<p>The latest version of this document is always available at
+<p class="fineprint"><em>
+ The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/faq/">
http://gcc.gnu.org/onlinedocs/libstdc++/faq/</a>. The main documentation
page is at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html">
http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html</a>.
-</p>
+</em></p>
-<p>To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
-</p>
+<p><em>
+ To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
+</em></p>
<!-- ####################################################### -->
<hr />
<li><a href="#3_5"><code>_XOPEN_SOURCE</code> /
<code>_GNU_SOURCE</code> / etc is always defined</a>
</li>
- <li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a> </li>
+ <li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a></li>
+ <li><a href="#3_7">Threading is broken on i386</a></li>
+ <li><a href="#3_8">Recent GNU/Linux glibc required?</a></li>
+ <li><a href="#3_9">Can't use wchar_t/wstring on FreeBSD</a></li>
</ol>
</li>
<em>constraints</em> in the STL...</a> </li>
<li><a href="#4_4_dlsym">program crashes when using library code
in a dynamically-loaded library</a> </li>
+ <li><a href="#4_4_leak">"memory leaks" in containers</a> </li>
</ul>
</li>
<li><a href="#4_5">Aw, that's easy to fix!</a> </li>
ongoing project to implement the ISO 14882 Standard C++ library
as described in chapters 17 through 27 and annex D. As the
library reaches stable plateaus, it is captured in a snapshot
- and released. The current release is
+ and released. The latest release is
<a href="http://gcc.gnu.org/libstdc++/index.html#download">the
- fourteenth snapshot</a>. For those who want to see exactly how
+ fourteenth snapshot</a> but newer versions have been included
+ in recent GCC releases. For those who want to see exactly how
far the project has come, or just want the latest
bleeding-edge code, the up-to-date source is available over
- anonymous CVS, and can even be browsed over the Web (see below).
+ anonymous CVS, and can even be browsed over the Web (see
+ <a href="#1_4">1.4</a> below).
</p>
<p>The older libstdc++-v2 project is no longer maintained; the code
has been completely replaced and rewritten.
stuff" classes will probably migrate there.)
</p>
<p>For the bold and/or desperate, the
- <a href="http://gcc.gnu.org/fom_serv/cache/33.html">GCC FAQ</a>
+ <a href="http://gcc.gnu.org/extensions.html">GCC extensions page</a>
describes where to find the last libg++ source.
</p>
</p>
<hr />
+ <h2><a name="3_7">3.7 Threading is broken on i386</a></h2>
+ <p>Support for atomic integer operations is/was broken on i386
+ platforms. The assembly code accidentally used opcodes that are
+ only available on the i486 and later. So if you configured GCC
+ to target, for example, i386-linux, but actually used the programs
+ on an i686, then you would encounter no problems. Only when
+ actually running the code on a i386 will the problem appear.
+ </p>
+ <p>This is fixed in 3.2.2.
+ </p>
+
+<hr />
+ <h2><a name="3_8">3.8 Recent GNU/Linux glibc required?</a></h2>
+ <p>For 3.2.1 (shared library version 5.0.1) and later, the library
+ uses localization and formatting code from the system C library
+ (glibc) version 2.2.5. That version of glibc is over a year old
+ and contains necessary bugfixes. Many GNU/Linux distros make
+ glibc version 2.3.x available now.
+ </p>
+ <p>The guideline is simple: the more recent the C++ library, the
+ more recent the C library. (This is also documented in the main
+ GCC installation instructions.)
+ </p>
+
+<hr />
+ <h2><a name="3_9">3.9 Can't use wchar_t/wstring on FreeBSD</a></h2>
+ <p>At the moment there are a few problems in FreeBSD's support for
+ wide character functions, and as a result the libstdc++ configury
+ decides that wchar_t support should be disabled. Once the underlying
+ problems are fixed in FreeBSD (soon), the library support will
+ automatically enable itself.
+ </p>
+ <p>You can fix the problems yourself, and learn more about the situation,
+ by reading
+ <a href="http://gcc.gnu.org/ml/libstdc++/2003-02/subjects.html#00286">
+ this short thread</a> ("_GLIBCPP_USE_WCHAR_T undefined in
+ FreeBSD's c++config.h?").
+ </p>
+
+<hr />
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
<em>Note that this section can get rapdily outdated -- such is the
nature of an open-source project. For the latest information, join
and unmaintained. Do not report problems with -v2 to the -v3
mailing list.
</p>
- <p>Currently our header files are installed in
- <code>${prefix}/include/g++-v3</code> (see the 'v'?). This may
- change with the next release of GCC, as it may be too confusing,
- but <a href="http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html">the
- question has not yet been decided</a>.
+ <p>For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are
+ installed in <code>${prefix}/include/g++-v3</code> (see the 'v'?).
+ Starting with version 3.2 the headers are installed in
+ <code>${prefix}/include/c++/${version}</code> as this prevents
+ headers from previous versions being found by mistake.
</p>
<p><a name="4_4_glibc"><strong>glibc</strong></a>
If you're on a GNU/Linux system and have just upgraded to
// link the executable
g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</pre>
+ <p><a name="4_4_leak"><strong>"memory leaks" in containers</strong></a>
+ A few people have reported that the standard containers appear
+ to leak memory when tested with memory checkers such as
+ <a href="http://developer.kde.org/~sewardj/">valgrind</a>.
+ The library's default allocators keep free memory in a pool
+ for later reuse, rather than returning it to the OS. Although
+ this memory is always reachable by the library and is never
+ lost, memory debugging tools can report it as a leak. If you
+ want to test the library for memory leaks please read
+ <a href="../debug.html#mem">Tips for memory leak hunting</a>
+ first.
+ </p>
<hr />
<h2><a name="4_5">4.5 Aw, that's easy to fix!</a></h2>
that of other headers whose directories are not searched directly,
e.g., <code><sys/stat.h></code>, <code><X11/Xlib.h></code>.
</p>
+
+ <p>The extensions are no longer in the global or <code>std</code>
+ namespaces, instead they are declared in the <code>__gnu_cxx</code>
+ namespace. For maximum portability, consider defining a namespace
+ alias to use to talk about extensions, e.g.:
+ </p>
+ <pre>
+ #ifdef __GNUC__
+ #if __GNUC__ < 3
+ #include <hash_map.h>
+ namespace Sgi { using ::hash_map; }; // inherit globals
+ #else
+ #include <ext/hash_map>
+ #if __GNUC_MINOR__ == 0
+ namespace Sgi = std; // GCC 3.0
+ #else
+ namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
+ #endif
+ #endif
+ #else // ... there are other compilers, right?
+ namespace Sgi = std;
+ #endif
+
+ Sgi::hash_map<int,int> my_map; </pre>
+ <p>This is a bit cleaner than defining typedefs for all the
+ instantiations you might need.
+ </p>
+
<p>Extensions to the library have
<a href="../ext/howto.html">their own page</a>.
</p>