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
