libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCO/bugfix patch 4 of 10: ltmain.in rpath variable


From: Ralf Wildenhues
Subject: Re: SCO/bugfix patch 4 of 10: ltmain.in rpath variable
Date: Mon, 31 Oct 2005 14:12:52 +0100
User-agent: Mutt/1.5.11

Hi Kean,

* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:04:42AM CET:
> 
> On SCO platforms it is very important to be able to create shared
> libaries with absolute SONAME entries, and to have executables that
> use those hard-coded names and not rely on DT_RUNPATH. The problem is
> that only relatively recent versions of the OS had protection in the
> RTLD against using LD_LIBRARY_PATH with elevated priveliges. Being
> able to divert a library in a program with elevated priveliges is a
> huge security risk. So the SCO patch (see next mail) provides the
> facility to set absolute path names in shared libraries if the
> environment variable `SCOABSPATH' is non-empty. In order for this to
> work, libtool needs to know what the installation path of the shared
> library is going to be. This is the value of -rpath. The problem with
> the current mechanism is that -rpath accumulates args, and adds spaces.
> I don't know if specifying multiple -rpath's has meaning to any platform,
> so to be on the safe side, rather than making rpath be a non-accumulating
> variable, I introduce a new variable called 'instrpath' that is set to
> whatever the last -rpath argument was.

Aren't you looking for install_libdir?

If yes, this patch is not needed (and discussion can be deferred until
the other patch, the one that uses it).  Also note that it picks up the
first `-rpath' argument given, not the last one.

Cheers,
Ralf

*snip*
> 2005-10-24  Kean Johnston  <address@hidden>
> 
>       * ltmain.in: Set a non-accumulating installation
>       rpath variable to facilitate setting absolute paths in shared
>       libraries.
*snip*




reply via email to

[Prev in Thread] Current Thread [Next in Thread]