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
