Hi --
I've encountered some issues with the apr-util build/configure
system that I thought I might pass on for wiser minds than mine
to review.
The crux of the problem seems to be twofold. First, it's
unclear to me what provision the apr-util build system has for
libraries (such as commercial binary-only libraries) that lack
.la libtool archive files. My current solution to that problem
is to add -R/path/to/lib alongside the -L/path/to/lib in the
apr-util buildconf process. (Bear with me if it seems dumb to
be fiddling with the buildconf process.)
Second, because the httpd build process depends on the output
from apu-1-config, and specifically the output of
apu-1-config --ldflags and --libs, certain types of library
dependency problems get passed along to it, and I'm not sure
that's really necessary.
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.
Here's a second level of detail. So long as the libraries
that are detected by the autoconf process have .la libtool
archive files as well as the .so files, all is well.
If one has a library that lacks a .la file, though, trouble
creeps in. (If you're thinking, "Don't do that!", do bear with me.)
You can simulate this problem by, for example, hiding your
normal iconv libraries, installing new ones in a private location,
and then removing the .la files.
The libaprutil-1.so library still builds and installs "OK",
but contains a problem that crops up when you run "make check":
it has unresolved paths to its dependent libraries. Probing with
ldd will show, for example:
libiconv.so.2 => not found
If you then compile httpd with this libaprutil-1.so, it'll
do so but fail to run with the obvious error, "libiconv.so.2:
cannot open shared object file: No such file or directory".
So that's the first problem, in essence -- lack of .la files
causes the libaprutil-1.so library to have undefined paths to
its dependent libraries, even though it compiled "OK".
The next problem -- if indeed it is one -- turned up as I
began to investigate ways to solve the first one. My initial
attempt was to hack into apr-util's build/rules.mk file and
add something like:
NOTEST_LDFLAGS=-R/path/to/lib
The purpose here is to ensure that the -R option gets added
to the libtool command link created by $LINK in rules.mk, and
specifically somewhere after $COMPILE, i.e., like this:
.../libtool ... --mode=link ... gcc ... \
-version-info 2:1:2 ... -R/path/to/lib ...
This corresponds to the advice I could find in the libtool
info pages; see, for example, libtool --mode=link --help.
Now I didn't have a working solution yet, because this was
just a post-buildconf, post-configure hack. But, OTOH, the
libaprutil-1.so was OK, with no undefined dependencies listed
by ldd.
OK, so now I went over and compiled and installed my httpd.
But it didn't run, with the same old error: "libiconv.so.2:
cannot open shared object file...." Checking the httpd
binary with ldd, I see that it has, weirdly:
libiconv.so.2 => not found
...
libiconv.so.2 => /path/to/lib/libiconv.so.2
Huh? This appears to be the consequence of building httpd
with the output of apu-1-config --libs and --ldflags. The final
step of the httpd make process is, roughly:
.../libtool --mode=link ... $EXTRA_LDFLAGS ... $EXTRA_LIBS ...
where EXTRA_LDFLAGS contains the output of apu-1-config --ldflags
and EXTRA_LIBS contains the output of apu-1-config --libs.
And EXTRA_LDFLAGS doesn't contain my -R/path/to/lib hack because
I slipped it into apr-util's build/rules.mk by hand, after
running configure, so it's not in apr-1-config.
So the second problem -- if it is one -- is that because
httpd's configure process imports the list of -L and -l (and -I)
options from apr-util (and apr too, of course), it re-links
the httpd binary against libraries that perhaps it does not
need to. In the contrived instance above, I'm not sure if there's
any reason for httpd to link against -liconv: after all, that's
a dependency of libaprutil-1.so, not httpd.
My understanding from the libtool documentation is that certain
older Unix-like systems, such as perhaps AIX, don't allow inter-
library dependencies. So that may be the reason for importing
the whole list of -L and -l options from apr and apr-util, even
on a system like Linux or Solaris, where inter-library dependencies
are resolved by ld.
Still, I thought I'd point it out, because it only turned up
as a result of an unusual hack, but then it did occur to me to
wonder why httpd needed to link against libraries that apr-util
abstracts and "hides".
So that's a summary, now some rationale. The use of libiconv
in the examples above was just for demonstration (but it is
reproducible, if you remove the .la file). My real problem is
with certain commercial libraries that are distributed as
binaries, and without .la files, specifically Oracle's
libclntsh.so. I've been working with Nick Kew to complete
a first pass at the code for an apr_dbd_oracle.c driver and
accompanying autoconf magic. So far, my best solution to the
problems described above is what I initially stated: add -R to
APRUTIL_LDFLAGS alongside the -L for Oracle's library.
This -R solves the first problem by ensuring that
libaprutil-1.so has no dependency problems itself.
Next, because it gets output by apu-1-config --ldflags, it's
used during httpd's compilation as well, so the fact that
httpd re-links against Oracle's library (because of the -l output
by apu-1-config --libs) doesn't cause dependency problems
either; probing the resultant httpd with ldd reveals that
it lists libclntsh.so twice, both with full paths and no
"not found" problems.
Still, as I said, it seems odd for httpd to need to link
against Oracle's library when it's fully abstracted behind
apr-util, at least on an OS that supports inter-library
dependencies.
Thus, back to my original question: is -R appropriate?
Is there a better way of linking against non-libtool-generated
libraries?
I should say, this is all on Linux, specifically RedHat;
libtool 1.5.6, autoconf 2.59, ld 2.15.92.0.2, gcc 3.4.3,
apr 1.2.1, apr-util 1.2.1, and httpd 2.1.8-beta.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
