This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Shared library runpath trouble in Solaris.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]