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: 11 Nov 1997 00:36:33 -0200
- Cc: tot at trema dot com, egcs at cygnus dot com
- References: <199711101827.NAA03006@subrogation.cygnus.com>
Ian Lance Taylor writes:
> You can't append a directory to the end of the shared library search
> path. The -R option prepends the directory to the start of the search
> path.
So g++ should invoke the linker like this:
ld -R/path/to/libstdc++ -R/usr/lib -R/whatever/-R/flags/issued/by/the/user
> You didn't consider the case where libstdc++ is not shared at all, or
> where the program does not use it.
I did, and I haven't noticed yet why it would break.
> IMHO, the most common situation is building a program a trying to run
> it, and not having an NFS-server down.
> Certainly. The problem arises when you link all your programs such
> that they have an NFS directory on the search path, and the server
> goes down, and suddenly you can't run any of your programs.
Only if the libstdc++ directory is searched before others.
> It would be possible to do something clever in collect2, like doing
> the library searching there, and automatically adding the -R option if
> the linker is going to wind up using a shared library.
This should only be done for libstdc++, otherwise libtool would
break.
> Individuals can solve this problem by using -R options when they link,
> or by setting the LD_RUN_PATH environment variable when linking to the
> directories they want searched at run time, or by setting the
> LD_LIBRARY_PATH environment variable when actually running the
> program.
Which is as portable as, say, ActiveX :-)
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil