This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: exes can't find libstdc++.so without help
- To: carlo at alinoe dot com (Carlo Wood)
- Subject: Re: exes can't find libstdc++.so without help
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Thu, 5 Jul 2001 17:20:49 -0700 (PDT)
- Cc: pedwards at disaster dot jaj dot com (Phil Edwards), neil dot bird at uk dot thalesgroup dot com (Neil Bird), gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
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.