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:

> 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


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