Chapter 3. Using

Table of Contents

Linking Library Binary Files
Headers
Header Files
Mixing Headers
The C Headers and namespace std
Precompiled Headers
Namespaces
Available Namespaces
namespace std
Using Namespace Composition
Macros
Concurrency
Prerequisites
Thread Safety
Atomics
IO
Containers
Exceptions
Propagating Exceptions aka Exception Neutrality
Exception Safety
Support for -fno-exceptions
Debugging Support
Using g++
Debug Versions of Library Binary Files
Memory Leak Hunting
Using gdb
Tracking uncaught exceptions
Debug Mode
Compile Time Checking

Linking Library Binary Files

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:

  • At runtime set LD_LIBRARY_PATH in your environment correctly, so that the shared library for libstdc++ can be found and loaded. Be certain that you understand all of the other implications and behavior of LD_LIBRARY_PATH first (few people do, and they get into trouble).

  • Compile the path to find the library at runtime into the program. This can be done by passing certain options to g++, which will in turn pass them on to the linker. The exact format of the options is dependent on which linker you use:

    • GNU ld (default on Linux):-Wl,--rpath,destdir/lib

    • IRIX ld: -Wl,-rpath,destdir/lib

    • Solaris ld:-Wl,-Rdestdir/lib

    • More...? Let us know!

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

A libstdc++.la file is also installed, for use with Libtool. If you use Libtool to create your executables, these details are taken care of for you.