httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: RUNPATH for module dependencies on Unix/Linux
Date Tue, 05 Jul 2011 08:13:16 GMT
Hi Joe,

On 05.07.2011 09:46, Joe Orton wrote:
> On Mon, Jul 04, 2011 at 09:07:49PM +0200, Rainer Jung wrote:
>> Hi everyone,
>>
>> a couple of modules have additional external dependencies:
>>
>> mod_deflate: zlib
>> mod_lua: lua
>> mod_serf: serf
>> mod_socache_dc: distcache
>>
>> At the moment, the compiled modules do not contain any RPATH/RUNPATH
>> info except when the libraries themselves are installed as libtool
>> libraries, i.e. have accompanying *.la files.
>>
>> The original distcache, zlib and lua distributions by default do not
>> install .la libtool files. It is of course possible, that distros
>> provide such files.
> 
> It looks like distcache (1.4.5 at least) does install the .la files?

Yes, sorry, distcache and serf do, zlib and lua don't.

> ...
>> Last remark: of course the "-R ..." will only be added if the libs are 
>> installed in non-default locations, i.e. if --with-LIB=DIR is given.
> 
> That sounds simple but it rarely is, in my experience.  You need a bunch 
> of heuristics and as often as not, these will do the wrong thing in some 
> cases as well as the right thing in others; so the net gain is hard to 
> judge.  Notably, adding RPATHs by default can produce binaries which are 
> not relocatable within the filesystem, which can be surprising 
> behaviour.

OK

> 1) How can you tell whether you are linking against a static library or 
> a shared library?  RPATHs are only needed if using a shared library

Haven't thought about that case.

> 2) How can you tell whether a given path is a "non-default location"?  
> To be strictly correct, you need to add an RPATH iff it is not already 
> configured in the dynamic linker search path - which you'd need to parse 
> system config files to determine.  This gets messy very quickly.

I would have redefined "non-default location" by "explicit
--with-LIB=DIR provided for configure". That is not "strictly correct"
(far from it).

> IMO it is much better to leave this stuff in the control of people who 
> build the software, who can already set env vars or LDFLAGS as they 
> require.  (It would also be much better if everybody used libtool, since 
> as you say, the .la files make this problem goes away :)

So would you also remove the current "ap_platform_runtime_link_flag"
hack, which we only use for Solaris and which adds "-R ..."
unconditional? Or should we stick, because although it is not right it
is what did work in the past (for Solaris)?

I will think about a good way, how users can pass additional LDADD
flags. Putting the "-R ..." into the LDFLAGS seems to be too heavy,
because then the RPATH of every module etc. will contain the given
directory. The real problematic cases are only mod_lua and in rare
circumstances (you want to link against a non-standard zlib)
mod_deflate. It might be enough to use APR_ADDTO() instead of direct
assignment or APR_SETVAR() when setting the LDADD variables. I'll
experiment.

Regards,

Rainer

Mime
View raw message