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: Joe Buck <jbuck at synopsys dot COM>
- Subject: Re: exes can't find libstdc++.so without help
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 05 Jul 2001 22:11:43 -0300
- Cc: carlo at alinoe dot com (Carlo Wood), 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
- Organization: GCC Team, Red Hat
- References: <200107060020.RAA01995@racerx.synopsys.com>
On Jul 5, 2001, Joe Buck <jbuck@synopsys.COM> wrote:
> 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.
Or set LD_LIBRARY_PATH so that, even though libstdc++.so isn't in the
hard-wired search PATH, it can still be found. Or get the dynamic
linker to search by default the directory containing libstdc++.so on
the other machine.
In general, the approach of hard-wiring pathnames is only a problem
when (i) the hard-wired pathname happens to be in an NFS mount-point
that is mounted, but down, so NFS will keep retrying until it times
out (with -o soft) or the server comes back up, or (ii) a hard-wired
pathname happens to contain a library that, in spite of having the
same soname, is not binary-compatible with the one the program was
linked with.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me