apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: apr-util config, etc.
Date Tue, 15 Nov 2005 21:39:33 GMT
Justin:

>>    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.)
> 
> Yes, the -L flag needs to be added by configure.  Otherwise, it won't know 
> what to do.  =)

   Right ... I misspoke there slightly.  What I mean is that,
for me at least, doing just this:

./configure --with-dbm=db43 \
  --with-berkeley-db=/path/to/bdb/include:/path/to/bdb/lib \
  ...

isn't sufficient, because although configure internally adds
-L/path/to/bdb/lib when compiling its test programs, they
still fail to execute without an additional -R option.  So,
doing this:

LDFLAGS=-Wl,-R/path/to/bdb/lib \
  ./configure --with-dbm=db43 \
  --with-berkeley-db=/path/to/bdb/include:/path/to/bdb/lib \
  ...

works nicely.  The -Wl,-R is passed to gcc when compiling the
test programs during configure, the test programs execute,
and configure accepts that Berkeley has been found.  But that's
all just a tangent.  :-)


>>    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
> 
> Well, it should be preserved in the GNU libtool interfaces.  That means 
> that if you perform a libtool link against libaprutil-1.la, the run-time 
> linker flags should be preserved.
>
> There are some version of GNU libtool that are broken in this respect 
> though.  Please ensure you are running the latest version of GNU libtool 
> (1.5.20 should work fine).  IIRC, all 1.5.x version of GNU libtool prior to 
> 1.5.10 are broken on most platforms in this regard.

   I'm running 1.5.14, because that's what is packaged in
apr 1.2.1.  I'm sort of inclinded not to fool with that, since
it's what other folks will be using too, I assume.  (Note: I
had initially said 1.5.6, but that's because I was testing the
system's libtool, not apr's.)

   Looking at libaprutil-1.la, nothing that I put in LDFLAGS or
NOTEST_LDFLAGS prior to running configure shows up.  I see my LDFLAGS
values in config.nice, but nowhere else.  Note that I'm running
only apr-util's configure script here.

   I see that apr-util's configure script simply copies its
build/rules.mk from apr, at line 168 of configure.in:

cp $APR_BUILD_DIR/apr_rules.mk $abs_builddir/build/rules.mk

   So that's perhaps the key to my trouble.  I was expecting that
setting LDFLAGS prior to running apr-util's configure would
work similarly to apr's, but it appears only to affect the test
programs; once the make process begins, the values from
build/rules.mk (aka apr's apr_rules.mk) take over, and whatever I
put in my env vars is lost.


> I'm not sure what your problem is here.
> 
> Can you provide some more details?

   Well, working backwards, my problem is this: I've got a
commerical library that lacks a .la file.  That seems to
require a -R flag to libtool and ld; otherwise, libaprutil-1.so
is built with an unresolved dependency (the path to Oracle's
library is "not found" when listed by ldd).

   Now, if putting -R into the buildconf/configure process
isn't advisable, I still need some way to get it into the final
libtool --mode=link step.  That step is generated by the $LINK
variable in build/rules.mk.  The -R has to appear after the $COMPILE
value (i.e., after the "gcc" LINK-COMMAND to libtool).  That means it
needs to get into $ALL_LDFLAGS, which means it needs to come from
$LDFLAGS, $EXTRA_LDFLAGS, or $NOTEST_LDFLAGS in build/rules.mk.

   But, that whole file seems to come out of apr, not apr-util.
So what do I advise people who might want to compile apr-util
with apr_dbd_oracle.c to do?  I guess I have to tell them to go
back to apr, re-build that with LDFLAGS=-R/path/to/oracle/lib,
re-install, and then do apr-util.

   That seems wrong to me, though -- if adding -R options
automatically is verboten in the configure process, then I'd
hope for a way to do so through LDFLAGS or a similar env var
prior to running apr-util's configure (i.e., after you've
read that ./configure --help :-)

   Thanks for all the help and insightful queries,

Chris.

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

Mime
View raw message