index.txt

linux下的gcc编译器

   to be able to share code, the final libstdc++ should, in theory, be
   usable under any ISO-compliant compiler. It will still be targeted and
   optimized for GCC/g++, however.
     _________________________________________________________________

3.2 [removed]

   This question has become moot and has been removed. The stub is here
   to preserve numbering (and hence links/bookmarks).
     _________________________________________________________________

3.3 [removed]

   This question has become moot and has been removed. The stub is here
   to preserve numbering (and hence links/bookmarks).
     _________________________________________________________________

3.4 I can't use 'long long' on Solaris

   By default we try to support the C99 long long type. This requires
   that certain functions from your C library be present.

   Up through release 3.0.2 the tests performed were too general, and
   this feature was disabled when it did not need to be. The most
   commonly reported platform affected was Solaris.

   This has been fixed for 3.0.3 and onwards.
     _________________________________________________________________

3.5 _XOPEN_SOURCE / _GNU_SOURCE / etc is always defined

   On Solaris, g++ (but not gcc) always defines the preprocessor macro
   _XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This
   is not an exhaustive list; other macros and other platforms are also
   affected.)

   These macros are typically used in C library headers, guarding new
   versions of functions from their older versions. The C++ standard
   library includes the C standard library, but it requires the C90
   version, which for backwards-compatability reasons is often not the
   default for many vendors.

   More to the point, the C++ standard requires behavior which is only
   available on certain platforms after certain symbols are defined.
   Usually the issue involves I/O-related typedefs. In order to ensure
   correctness, the compiler simply predefines those symbols.

   Note that it's not enough to #define them only when the library is
   being built (during installation). Since we don't have an 'export'
   keyword, much of the library exists as headers, which means that the
   symbols must also be defined as your programs are parsed and compiled.

   To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the
   gcc config headers for your target (and try changing them to see what
   happens when building complicated code). You can also run "g++ -E -dM
   - < /dev/null" to display a list of predefined macros for any
   particular installation.

   This has been discussed on the mailing lists [76]quite a bit.

   This method is something of a wart. We'd like to find a cleaner
   solution, but nobody yet has contributed the time.
     _________________________________________________________________

3.6 OS X ctype.h is broken! How can I hack it?

   This is a long-standing bug in the OS X support. Fortunately, the
   patch is quite simple, and well-known. [77]Here's a link to the
   solution.
     _________________________________________________________________

3.7 Threading is broken on i386

   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.

   This is fixed in 3.2.2.
     _________________________________________________________________

3.8 Recent GNU/Linux glibc required?

   When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
   5.0.1) and later 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.

   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.)
     _________________________________________________________________

3.9 Can't use wchar_t/wstring on FreeBSD

   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.

   You can fix the problems yourself, and learn more about the situation,
   by reading [78]this short thread ("_GLIBCPP_USE_WCHAR_T undefined in
   FreeBSD's c++config.h?").
     _________________________________________________________________

3.10 MIPS atomic operations

   The atomic locking routines for MIPS targets requires MIPS II and
   later. A patch went in just after the 3.3 release to make mips* use
   the generic implementation instead. You can also configure for
   mipsel-elf as a workaround.

   mips*-*-linux* continues to use the MIPS II routines, and more work in
   this area is expected.
     _________________________________________________________________

                          4.0 Known Bugs and Non-Bugs

   Note that this section can get rapdily outdated -- such is the nature
   of an open-source project. For the latest information, join the
   mailing list or look through recent archives. The RELEASE- NOTES and
   BUGS files are generally kept up-to-date.

   For 3.0.1, the most common "bug" is an apparently missing "../" in
   include/Makefile, resulting in files like gthr.h and gthr-single.h not
   being found. Please read [79]the configuration instructions for GCC,
   specifically the part about configuring in a separate build directory,
   and how strongly recommended it is. Building in the source directory
   is fragile, is rarely tested, and tends to break, as in this case.
   This was fixed for 3.0.2.

   For 3.1, the most common "bug" is a parse error when using <fstream>,
   ending with a message, "bits/basic_file.h:52: parse error before `{'
   token." Please read [80]the installation instructions for GCC,
   specifically the part about not installing newer versions on top of
   older versions. If you install 3.1 over a 3.0.x release, then the
   wrong basic_file.h header will be found (its location changed between
   releases).

   Please do not report these as bugs. We know about them. Reporting this
   -- or any other problem that's already been fixed -- hinders the
   development of GCC, because we have to take time to respond to your
   report. Thank you.

4.1 What works already?

   Short answer: Pretty much everything works except for some corner
   cases. Also, localization is incomplete. For whether it works well, or
   as you expect it to work, see 5.2.

   Long answer: See the docs/html/17_intro/CHECKLIST file, which is badly
   outdated...

   What follows is a verbatim clip from the "Status" section of the
   RELEASE-NOTES for the latest snapshot. For a list of fixed bugs, see
   that file.
New:
     _________________________________________________________________

4.2 Bugs in gcc/g++ (not libstdc++-v3)

   This is by no means meant to be complete nor exhaustive, but mentions
   some problems that users may encounter when building or using
   libstdc++. If you are experiencing one of these problems, you can find
   more information on the libstdc++ and the GCC mailing lists.

   Before reporting a bug, examine the [81]bugs database with the
   category set to "libstdc++". The BUGS file in the source tree also
   tracks known serious problems.
     * Debugging is problematic, due to bugs in line-number generation
       (mostly fixed in the compiler) and gdb lagging behind the compiler
       (lack of personnel). We recommend configuring the compiler using
       --with-dwarf2 if the DWARF2 debugging format is not already the
       default on your platform. Also, [82]changing your GDB settings can
       have a profound effect on your C++ debugging experiences. :-)
     _________________________________________________________________

4.3 Bugs in the C++ language/lib specification

   Yes, unfortunately, there are some. In a [83]message to the list,
   Nathan Myers announced that he has started a list of problems in the
   ISO C++ Standard itself, especially with regard to the chapters that
   concern the library. The list itself is [84]posted on his website.
   Developers who are having problems interpreting the Standard may wish
   to consult his notes.

   For those people who are not part of the ISO Library Group (i.e.,
   nearly all of us needing to read this page in the first place :-), a
   public list of the library defects is occasionally published [85]here.
   Some of these have resulted in [86]code changes.
     _________________________________________________________________

4.4 Things in libstdc++ that only look like bugs

   There are things which are not bugs in the compiler (4.2) nor the
   language specification (4.3), but aren't really bugs in libstdc++,
   either. Really! Please do not report these as bugs.

   -Weffc++ The biggest of these is the quadzillions of warnings about
   the library headers emitted when -Weffc++ is used. Making libstdc++
   "-Weffc++-clean" is not a goal of the project, for a few reasons.
   Mainly, that option tries to enforce object-oriented programming,
   while the Standard Library isn't necessarily trying to be OO.

   reopening a stream fails Did I just say that -Weffc++ was our biggest
   false-bug report? I lied. (It used to be.) Today it seems to be
   reports that after executing a sequence like
    #include <fstream>
    ...
    std::fstream  fs("a_file");
    // .
    // . do things with fs...
    // .
    fs.close();
    fs.open("a_new_file");

   all operations on the re-opened fs will fail, or at least act very
   strangely. Yes, they often will, especially if fs reached the EOF
   state on the previous file. The reason is that the state flags are not
   cleared on a successful call to open(). The standard unfortunately did
   not specify behavior in this case, and to everybody's great sorrow,
   the [87]proposed LWG resolution in DR #22 is to leave the flags
   unchanged. You must insert a call to fs.clear() between the calls to
   close() and open(), and then everything will work like we all expect
   it to work.

   rel_ops Another is the rel_ops namespace and the template comparison
   operator functions contained therein. If they become visible in the
   same namespace as other comparison functions (e.g., 'using' them and
   the <iterator> header), then you will suddenly be faced with huge
   numbers of ambiguity errors. This was discussed on the -v3 list;
   Nathan Myers [88]sums things up here. The collisions with
   vector/string iterator types have been fixed for 3.1.

  The g++-3 headers are not ours

   If you have found an extremely broken header file which is causing
   problems for you, look carefully before submitting a "high" priority
   bug report (which you probably shouldn't do anyhow; see the last
   paragraph of the page describing [89]the GCC bug database).

   If the headers are in ${prefix}/include/g++-3, or if the installed
   library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so,
   then you are using the old libstdc++-v2 library, which is nonstandard
   and unmaintained. Do not report problems with -v2 to the -v3 mailing
   list.

   For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are
   installed in ${prefix}/include/g++-v3 (see the 'v'?). Starting with
   version 3.2 the headers are installed in
   ${prefix}/include/c++/${version} as this prevents headers from
   previous versions being found by mistake.

   glibc If you're on a GNU/Linux system and have just upgraded to glibc
   2.2, but are still using gcc 2.95.2, then you should have read the
   glibc FAQ, specifically 2.34:
2.34.   When compiling C++ programs, I get a compilation error in streambuf.h.

{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
apply a patch to the include files in /usr/include/g++, because the fpos_t
type has changed in glibc 2.2.  The patch is at
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff


   Note that 2.95.x shipped with the [90]old v2 library which is no
   longer maintained. Also note that gcc 2.95.3 fixes this problem, but
   requires a separate patch for libstdc++-v3.

   concept checks If you see compilation errors containing messages about
   fooConcept and a constraints member function, then most likely you
   have violated one of the requirements for types used during
   instantiation of template containers and functions. For example,
   EqualityComparableConcept appears if your types must be comparable
   with == and you have not provided this capability (a typo, or wrong
   visibility, or you just plain forgot, etc).

   More information, including how to optionally enable/disable the
   checks, is available [91]here.

   dlopen/dlsym If you are using the C++ library across
   dynamically-loaded objects, make certain that you are passing the
   correct options when compiling and linking:
    // compile your library components
    g++ -fPIC -c a.cc
    g++ -fPIC -c b.cc
    ...
    g++ -fPIC -c z.cc

    // create your library
    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o

    // link the executable
    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl

   "memory leaks" in containers A few people have reported that the
   standard containers appear to leak memory when tested with memory
   checkers such as [92]valgrind. 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 [93]Tips for
   memory leak hunting first.
     _________________________________________________________________

4.5 Aw, that's easy to fix!

   If you have found a bug in the library and you think you have a
   working fix, then send it in! The main GCC site has a page on
   [94]submitting patches that covers the procedure, but for libstdc++
   you should also send the patch to our mailing list in addition to the
   GCC patches mailing list. The libstdc++ [95]contributors' page also
   talks about how to submit patches.

   In addition to the description, the patch, and the ChangeLog entry, it
   is a Good Thing if you can additionally create a small test program to
   test for the presence of the bug that your patch fixes. Bugs have a
   way of being reintroduced; if an old bug creeps back in, it will be
   caught immediately by the [96]testsuite -- but only if such a test
   exists.
     _________________________________________________________________

                               5.0 Miscellaneous

5.1 string::iterator is not char*; vector<T>::iterator is not T*

   If you have code that depends on container<T> iterators being
   implemented as pointer-to-T, your code is broken.