[Top][All Lists]
[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*