apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] Add --with-efence option.
Date Fri, 14 Dec 2001 20:42:25 GMT
On Fri, Dec 14, 2001 at 10:00:28AM -0800, Justin Erenkrantz wrote:
> > Maybe I'm missing something, but I don't see how the library runtime
> > path would have any bearing on an AC test. It either links or it fails,
> > right?
> 
> Okay, say we do that.  Remember that AC_TRY_RUN will compile, link, 
> and run.  By that time we've done the following:
> 
> LDFLAGS="-Lpath/to/efence/lib -Rpath/to/efence/lib"
> LIBS="-lefence"
> 
> The autoconf tests are handled by $CC *not* libtool.  A linker that
> doesn't understand -R will die.  We don't use libtool until the
> make process begins.  Which means we need the platform-specific
> runtime linker flag at configure time.  When we do make, we can
> rely on libtool handling the -R though.
> 
> However, say we don't add the platform specific link flag, then all
> runs will fail on -R needing platforms since we linked against
> efence, but didn't specify where its runtime path was.  -- justin

Justin and I have come up with a proposal. (Justin: I'll expect you
to correct me if I misrepresent you.)

Why don't we rename some variables:
INCLUDES --> AP_INCLUDES
LIBS --> AP_LIBS
<null> --> AP_LDFLAGS

As we do our autoconf tests, we would slowly accumulate flags in the AP_*
vars as we do now with INCLUDES and LIBS, but right now we don't have a
protected LDFLAGS that won't get picked up by the AC tests. For the
above case with efence we'd do:

(pseudo-code):

AP_INCLUDES += "-I/path/where/we/found/efence/includes"
AP_LIBS += "-lefence"
AP_LDFLAGS += "-L/path/where/we/found/efence/libs -R/path/where/we/found/efence/libs"

-aaron

Mime
View raw message