exes can't find libstdc++.so without help

[Joe Buck]

Carlo Wood writes:
> Perhaps this can be put in the FAQ?

> When gcc-3.0 is installed in a non-standard prefix (not /usr or
> /usr/local etc), for instance as second compiler, then C++ programs can
> have a hard time finding the correct libstdc++ when being run.

The same was true of older compilers if configured with --enable-shared.
The difference is that now it's the default.
 
> This can be solved easily by including the path to libstdc++ (and other
> compiler version specific libraries) in the executable itself.  A
> disadvantage is that this will only work on the same machine as where
> the executable was built ...

That's incorrect as it vastly overstates the disadvantage.  The
executables will only work on a machine that has libstdc++.so
installed somewhere on the wired-in search path, but the executables can
still be portable.  It's just that any client has to put libstdc++.so
or a symbolic link to it in the right place.

Example: suppose I'm a GNU/Linux or BSD distributor, and I want to
make gcc-3.0 available, but not as the default compiler.  I configure it
with --prefix=/opt/gcc-3.0 and I hack it to wire in /opt/gcc-3.0/lib
in the search path.  Now I split it up into separate packages for the
compiler and the runtime.  Clearly anyone who installs the runtime can
run all executables, even if they are on a different machine.  In fact,
since what's being wired in is a path, not an absolute location, the
executables will also work on a system that has the 3.0 libstdc++.so
installed in /usr/lib.