This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shared library runpath trouble in Solaris.
- To: Ian Lance Taylor <ian at cygnus dot com>
- Subject: Re: Shared library runpath trouble in Solaris.
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 10 Nov 1997 16:12:22 -0200
- Cc: tot at trema dot com, egcs at cygnus dot com
- References: <199711101708.MAA16943@subrogation.cygnus.com>
Ian Lance Taylor writes:
> Optimizing away unused directories is essential. Your patch would
> impose the directory requirements on all C programs, which presumably
> do not use the shared libstdc++ anyhow.
Not if it only applies to C++ programs.
> It would also impose the directory requirements even on people who
> do not have a shared libstdc++.
If the shared libg++ directory is appended at the end of the library
search path, it will only be used if a library cannot be found in any
previous directory. Thus, since that is the last directory in the
search path, and the library has not been found in any other
directory, we have two possible scenarios:
1) the needed library *is* in the libstdc++ directory, so the
directory should be looked at anyway.
2) the needed library *is not* in the libstdc++ directory, so it is
unavailable. Even if the directory were a NFS-mount from a host that
is down, the program would not be able to run.
I vote for adding the directory that contains libstdc++ at the end of
the library run path, otherwise most people just won't use a shared
libstdc++, and will blame g++/egcs for created huge binary programs,
or will try to use a shared libstdc++ and blame g++/egcs for not being
able to find the library at runtime unless a special flag is given.
IMHO, the most common situation is building a program a trying to run
it, and not having an NFS-server down.
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil