libstdc++-v3 INSTALL

The latest version of this document is always available at http://sourceware.cygnus.com/libstdc++/install.html.

To the libstdc++-v3 homepage.

Contents

Tools you will need beforehand

You will need a recent version of g++ to compile the snapshot of libstdc++: gcc-2.95.2 works well, or one of the post-2.95.2 egcs snapshots (insert standard caveat about using snapshots rather than formal releases). You will need the full source distribution to whatever compiler release you are using. The GCC snapshots can be had from one of the sites on their mirror list.

In addition, if you plan to modify the makefiles or regenerate the configure scripts you'll need the nuevo automake (version 1.4 from Cygnus, not the one on the net. In addition, libtool and autoconf are also required to be installed in the same location as the new automake: you can get them all in one easy-to-use tarball here.

If you don't have bash, and want to run 'make check' to test your build, you'll need to get bash 2.x. Also recommended is GNU Make, since it is the only 'make' that will parse these makefiles correctly.

As of June 19, 2000, libstdc++ attempts to use tricky and space-saving features of the GNU toolchain, enabled with -ffunction-sections -fdata-sections -Wl,--gc-sections. To obtain maximum benefit from this, binutils after this date should also be used (bugs were fixed with c++ exception handling related to this change in libstdc++-v3.) The version of these tools should be: 2.10.90, and you can get snapshots (as well as releases) of binutils here.

Finally, if you are using cygwin to compile libstdc++-v3 on win32, you'll have to get a version of the cygwin.dll that is dated on or after February 1, 2000. This is necessary to successfully run the script "mknumeric_limits" which probes the floating-point environment of the host in question--before this date, Cygwin would freeze when running this script. In addition, you may want to get a current version of libtool (say libtool-1.3.4 and above) as earlier versions supposedly had problems creating shared libraries.

Setting up the source directories

As the libstdc++-v3 sources and the core GCC sources move towards convergence, more and more effort goes to building the library as the default version to be shipped with g++. With the 2.90.8 snapshot, and especially for CVS versions after this release, this is treated as the usual scenario. If you want to build the library all by itself, you will need to explicitly disable certain features (like namespaces) since the core GCC library, libgcc.a, will not be rebuilt with those same features.

By default, all configurations of libstdc++-v3 now have namespaces enabled. Being able to select/de-select this option was a complex task that had hopelessly confused many otherwise intelligent people, and provided an endless stream of silent cursing and cries for help. Because of this, gcc sources are required, and are no longer optional.

The following definitions will be used throughout the rest of this document:

Note:
  1. The .8 snapshot and following are intended to replace the library that comes with the compiler, so libsrcdir and libbuilddir must be contained under gccsrcdir and gccbuilddir, respectively.
  2. The source, build, and installation directories should not be parents of one another; i.e., these should all be separate directories. Please don't build out of the source directory.

Since the release of libstdc++-2.90.8, configuration patches have gone into CVS gcc that make the management of the various libstdc++ source trees a bit easier. Because of this, both libstdc++-v2 and libstdc++-v3 and live together more or less in peace, without the need for soft linking. If a CVS gcc source directory after April 5, 2000 is being used, then the directions are slightly different: please pick which of the following two scenarios best represents your particular situation.

...with gcc-2.95.2

Unpack the gccsrcdir and go into that directory. For instance, gcc-2.95.2 is a valid gccsrcdir. Once in gccsrcdir, you'll need to rename the directories called libstdc++ and libio like so: 

      mv libstdc++ libstdc++-v2
      mv libio libio-v2

Next, unpack the libstdc++-v3 library tarball into the gccsrcdir directory; it will create a libsrcdir called libstdc++-version: 

   gzip -dc libstdc++-version.tar.gz | tar xf -

Finally, make a soft link between libsrcdir and libstdc++ so that libstdc++-v3 will be the default C++ library used. 

   ln -s libsrcdir libstdc++
This complexity of having two completely separate libstdc++ libraries is necessary so that you can unlink libsrcdir and update the compiler sources. If you're not this adventurous, or would not like to switch between different C++ standard libraries, this extra effort is probably wasted; just remove the v2 sources.

...with CVS gcc

Check out or download the gcc sources: the resulting source director is gccsrcdir.

Next, unpack the libstdc++-v3 library tarball into this gccsrcdir directory; it will create a libsrcdir called libstdc++-version: 

   gzip -dc libstdc++-version.tar.gz | tar xf -

If CVS libstdc++-v3 is being used instead of a snapshot's tarball, then move the source directory from the cvs checkout into the gccsrcdir directory.

Finally, rename libsrcdir to libstdc++-v3 so that gcc's configure flags will be able to deal with the new library. 

   mv libsrcdir libstdc++-v3

Configuring

Due to namespaces, when building libstdc++-v3 you'll have to configure the entire gccsrcdir directory. The full list of libstdc++-v3 specific configuration options, not dependent on the specific compiler release being used, can be found here

[Consider possibly using --enable-languages=c++ to save time by only building the C++ language parts]

...with gcc-2.95.2

gccsrcdir/configure --prefix=destdir

...with CVS gcc

gccsrcdir/configure --prefix=destdir --enable-libstdcxx-v3

[Adding --enable-libstdcxx-v3 automatically selects libstdc++-v3 as the C++ library to be used alongside the C++ compiler being built, and also enables -fhonor-std by default. This option is not available with gcc-2.95.2]

Building and installing the library

Now you have a few options:

[re]building everything

If you're building GCC from scratch, you can do the usual 'make bootstrap' here, and libstdc++-v3 will be built as its default C++ library. The generated g++ will magically use the correct headers, link against the correct library binary, and in general using libstdc++-v3 will be a piece of cake. You're done; run 'make install' (the GCC Installation instructions) to put the new compiler and libraries into place.

[re]building only libstdc++

Due to differences in the configure process, the resulting Makefiles in thegccbuilddir will have different rules depending on the source base being used.

...with gcc-2.95.2

libstdc++-rule is libstdc++

...with CVS gcc

libstdc++-rule is libstdc++-v3

To rebuild just libstdc++, use: 

make all-target-libstdc++-rule
This will configure and build the C++ library in the gccbuilddir/cpu-vendor-OS/libstdc++ directory. As en example, for CVS gcc this would be make all-target-libstdc++-v3, and for gcc-2.95.2 it would be make all-target-libstdc++

If the build fails with a "warning: can't inline call" message when compiling stringMAIN.cc, see the resolution at the end of this document.

You're done. Now install the rebuilt pieces with 

   make install

   or 

   make install-gcc
   make install-target-libstdc++-rule

Post-installation

Installation will create the destdir directory and populate it with subdirectories: 

   lib/
   include/g++-v3/
      bits/
      backward/
      ext/

You can check the status of the build without installing it using 

   make check
or you can check the status of the installed library using 
   make check-target-libstdc++-rule
These commands will create a 'testsuite' directory underneath libbuilddir containing the results of the tests. We are interested in any strange failures of the testsuite; please see FAQ 2.4 for which files to examine.

Using the library

  • Find the new library at runtime (shared linking only)

    If you only built a static library (libstdc++.a), or if you specified static linking, you don't have to worry about this. But if you built a shared library (libstdc++.so) and linked against it, then you will need to find that library when you run the executable.

    Methods vary for different platforms and different styles, but the usual ones are printed to the screen during installation. They include:

    Use the ldd(1) utility to show which library the system thinks it will get at runtime.

    warning: can't inline call to...

    When building the .8 snapshot with g++ 2.95.2, compilation may halt with this warning message. The "problem" is the -Werror flag being passed to the compiler, which says to treat warnings as errors. (This plus a high warning level makes us track down bugs quickly.) The compiler can't inline a certain call, prints a warning, and dies.

    The workaround is to edit either libsrcdir/src/Makefile.in (before configuring) or bld-libstdc++/src/Makefile (after configuring). There's one line that reads 

       WERROR = -Werror
    Delete the flag itself, so that the line reads 
       WERROR =
    Then the compiler will still print a warning, but it won't die.

    For the curious, this "problem" is actually a symptom of something else. The compiler in CVS could inline more than what 2.95.2 does, and the libstdc++ changes were made with that compiler. One of the libstdc++ maintainers explains this here.

    This has been patched in current CVS sources.

    Comments and suggestions are welcome, and may be sent to Phil Edwards or Gabriel Dos Reis.
    $Id: install.html,v 1.3 2000/06/20 23:14:37 bkoz Exp $