Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <437A46D7.4020008@pearsoncmg.com>
Date: Tue, 15 Nov 2005 15:36:39 -0500
From: Chris Darroch <chrisd@pearsoncmg.com>
Organization: Pearson CMG
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: apr-util config, etc.
References: <437A3E66.8020707@pearsoncmg.com>
 <B1E0712FA1901D4715D5AD96@st-augustin.ics.uci.edu>
In-Reply-To: <B1E0712FA1901D4715D5AD96@st-augustin.ics.uci.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Justin:

>>    My ultimate question, for the impatient, is whether adding
>> -R to APRUTIL_LDFLAGS is an appropriate solution when using
>> libraries that one expects not to have accompanying .la files.
> 
> We've had this discussion several times.  There's a group of developers who 
> believe we should automatically add the -R flags and an equally vocal 
> developers who believe that the user must hand-edit ldconfig on their 
> platform.
> 
> At the moment, the folks who advocate not having the -R flag represent our 
> state of affairs.

   OK, understood, and sorry to recapitulate an old discussion.
(Also apologies for the strange subject line -- too much proofreading
of the body!)

> Setting LDFLAGS before running configure should work, like so:
> 
> LDFLAGS="-R/path/to/lib" \
> ./configure
> 
> is an acceptable workaround that should work.  It's what I use.

   I do the same to get Berkeley DB to work with apr-util, with
the -Wl,-R option.  That seems to be sufficient to ensure that
configure's test programs compile and execute.  (For some reason,
just having -L doesn't do it, and configure wrongly decides that
BDB can't be found because one of the test programs fails.)

   However, if I read the situation correctly, that LDFLAGS setting
doesn't actually make it into make process itself; certainly it
doesn't turn up outside of config.{log,nice,status} or in make's
output.  And in both the "fake" libiconv and "real" Oracle instances
I've tried, adding either -R or -Wl,-R to LDFLAGS or NOTEST_LDFLAGS,
etc., before running configure has no effect; libaprutil-1.so
is still built with an unresolved "not found" dependency, because
of the missing .la file and the fact that no -R option makes it
from my env vars into the make process.

   Now, maybe that's some other kind of problem -- should one be
able to do "NOTEST_LDFLAGS=... ./configure" and have those
values appear in, perhaps, build/rules.mk?  I'm not sure if
that's the intention or not from the comments in rules.mk.

   At any rate, I've still got a problem on my hands, because
to deal with Oracle I need to get something into $LINK after
$COMPILE, which means one of LDFLAGS, EXTRA_LDFLAGS, or
NOTEST_LDFLAGS in build/rules.mk.  No amount of fiddling
with prior-to-configure env vars has allowed me to do this;
although things turn up in config.nice, they don't make it
into the actual make process.  Any help appreciated!  Thanks!

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B