From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Oliva To: Ian Lance Taylor Cc: tot@trema.com, egcs@cygnus.com Subject: Re: Shared library runpath trouble in Solaris. Date: Mon, 10 Nov 1997 18:41:00 -0000 Message-id: References: <199711101827.NAA03006@subrogation.cygnus.com> X-SW-Source: 1997-11/msg00381.html 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