index.txt

gcc3.2.1源代码

     _________________________________________________________________

                         3.0 Platform-Specific Issues

3.1 Can libstdc++-v3 be used with <my favorite compiler>?

   Probably not. Yet.

   Because GCC advances so rapidly, development and testing of libstdc++
   is being done almost entirely under that compiler. If you are curious
   about whether other, lesser compilers (*grin*) support libstdc++, you
   are more than welcome to try. Configuring and building the library
   (see above) will still require certain tools, however. Also keep in
   mind that building libstdc++ does not imply that your compiler will be
   able to use all of the features found in the C++ Standard Library.

   Since the goal of ISO Standardization is for all C++ implementations
   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 [69]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. [70]Here's a link to the
   solution.
     _________________________________________________________________

                          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 [71]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 [72]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?

   This 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:
---
(post 3.0.97)
- more doxygen documentation
- more named locale fixups
- stdio_filebuf that takes fd, FILE
- io performance tuning
- allocation tuning, valgrind fixups
- __cxa_demangle now supported
(3.0.97)
- more doxygen documentation.
- more named locale bug fixes
- support for symbol versioning when using GNU ld >= 2.12
- wide-io
- tuning for executable size
(3.0.96)
- more doxygen documentation.
- extensions moved out of namespace std
- HPUX long long support
- more string optimizations
- support for NetBSD cross compiles
- concept_check merge from boost
- header simplification
- named locale bug shakeout
- thread testsuite
(3.0.95)
- add S390, m68k, x86-64 support.
- doxygen documentation has been extended, including man pages.
- verbose terminate handling has been added.
- some libsupc++ tweaks
- warnings for deprecated headers now active.
- dejagnu testsuite preliminary documentation.
- dejagnu testsuite default.
- dejagnu testsuite cross compiler, multilib safe.
- long long iostreams on by default, rework of ISO C99 support.
- iterator re-write and testsuites.
- container testsuites.
- allocator revamp and testsuites.
- more concept-checking work.
- basic_string optimization and MT fixes.
- new limits implementation.
- update -fno-exceptions code, verify it works.
- full named locale support fpr all facets, choice of gnu,
  ieee_1003.1-200x (POSIX 2), or generic models. Full support depends
  on target OS and underlying "C" library support.
     _________________________________________________________________

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 [73]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, [74]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 [75]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 [76]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 [77]here.
   Some of these have resulted in [78]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 [79]proposed LWG resolution (see 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 [80]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 [81]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.

   Currently our header files are installed in ${prefix}/include/g++-v3
   (see the 'v'?). This may change with the next release of GCC, as it
   may be too confusing, but [82]the question has not yet been decided.

   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 [83]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 [84]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 the library components
    g++ -fPIC -c a.cc
    g++ -fPIC -c b.cc
    ...
    g++ -fPIC -c z.cc

    // create the 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
     _________________________________________________________________

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
   [85]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++ [86]contributors' page also