index.txt

linux下编程用 编译软件

   need a single function or variable from an object file, the entire
   object file is extracted. (There's nothing unique to C++ or
   libstdc++-v3 about this; it's just common behavior, given here for
   background reasons.)

   Some of the object files which make up libstdc++.a are rather large.
   If you create a statically-linked executable with -static, those large
   object files are suddenly part of your executable. Historically the
   best way around this was to only place a very few functions (often
   only a single one) in each source/object file; then extracting a
   single function is the same as extracting a single .o file. For
   libstdc++-v3 this is only possible to a certain extent; the object
   files in question contain template classes and template functions,
   pre-instantiated, and splitting those up causes severe maintenance
   headaches.

   It's not a bug, and it's not really a problem. Nevertheless, some
   people don't like it, so here are two pseudo-solutions:

   If the only functions from libstdc++.a which you need are language
   support functions (those listed in [78]clause 18 of the standard,
   e.g., new and delete), then try linking against libsupc++.a (Using gcc
   instead of g++ and explicitly linking in -lsupc++ for the final link
   step will do it). This library contains only those support routines,
   one per object file. But if you are using anything from the rest of
   the library, such as IOStreams or vectors, then you'll still need
   pieces from libstdc++.a.

   The second method is one we hope to incorporate into the library build
   process. Some platforms can place each function and variable into its
   own section in a .o file. The GNU linker can then perform garbage
   collection on unused sections; this reduces the situation to only
   copying needed functions into the executable, as before, but all
   happens automatically.

   Unfortunately the garbage collection in GNU ld is buggy; sections
   (corresponding to functions and variables) which are used are
   mistakenly removed, leading to horrible crashes when your executable
   starts up. For the time being, this feature is not used when building
   the library.
     _________________________________________________________________

2.6 Why do I get an error saying libstdc++.so.X is missing when I run my
program?

   Depending on your platform and library version, the message might be
   similar to one of the following:
    ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open
shared object file: No such file or directory

    /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found

   This doesn't mean that the shared library isn't installed, only that
   the dynamic linker can't find it. When a dynamically-linked executable
   is run the linker finds and loads the required shared libraries by
   searching a pre-configured list of directories. If the directory where
   you've installed libstdc++ is not in this list then the libraries
   won't be found. The simplest way to fix this is to use the
   LD_LIBRARY_PATH environment variable, which is a colon-separated list
   of directories in which the linker will search for shared libraries:
    LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH

   The exact environment variable to use will depend on your platform,
   e.g. DYLD_LIBRARY_PATH for Darwin,
   LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,
   LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and
   SHLIB_PATH for HP-UX.

   See the man pages for ld(1), ldd(1) and ldconfig(8) for more
   information. The dynamic linker has different names on different
   platforms but the man page is usually called something such as ld.so /
   rtld / dld.so.
     _________________________________________________________________

                         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 [79]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. [80]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 [81]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 [82]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 [83]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... Also see the RELEASE-NOTES file, which is kept more up to
   date.
     _________________________________________________________________

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 [84]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, [85]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 [86]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 [87]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.,