Apache 2.2.9 default bindist/apr library problem

Hi all,
We noticed that with Apache 2.2.9 when the bundled APR is used, the
bindist installation ends up having the following structure in bindist/lib:
/pkgconfig
/pkgconfig/apr-1.pc
/pkgconfig/apr-util-1.pc
/libapr-1.so.0.3.0
/libapr-1.so.0
/libapr-1.so
/libapr-1.la
/libapr-1.a
/apr.exp
/apr-util-1
/apr-util-1/apr_ldap-1.so
/apr-util-1/apr_ldap.so
/apr-util-1/apr_ldap.la
/apr-util-1/apr_ldap.a
/libexpat.so.0.1.0
/libexpat.so.0
/libexpat.so
/libexpat.la
/libexpat.a
/libaprutil-1.so.0.3.0
/libaprutil-1.so.0
/libaprutil-1.so
/libaprutil-1.la
/libaprutil-1.a
/aprutil.exp

There's the addition of apr-util-1/apr_ldap* files.

The default envvars script is still built with only
/usr/local/apache2/lib in the LD_LIBRARY_PATH and apr-util/Makefile defines:
LINK_MDULE = $(LIBTL) $(LTFLAGS) $(CC) $(LT_LDFLAGS)
$(ALL_CFLAGS) $(ALL_LDFLAGS) $(APRUTIL_LDFLAGS) -release
$(APRUTIL_MAJR_VERSIN) -module -rpath $(APU_DSLIBDIR)
APU_DSLIBDIR = ${libdir}/apr-util-1

so the libraries are pathed with ${libdir}/apr-util-1 directory in their
path.

As a result, the bindist installed Apache 2.2.9 isn't able to find
apr_ldap*.so.

Simple enough to workaround in envvars, but is the intention to continue
to put libraries in subdirectories under apache/lib or was this an
oversite? Either way, envvars needs to be updated to include any new
libraries for a bindist situation correct?

Andy

William A. Rowe, Jr. wrote:
Eric Covener wrote:
>>
>case to keep on the radar: There can be configuration mechanisms
>for the loader outside of the SHLIB_PATH envvar. If this is apr-util
>in /usr/lib, so no shlib-path-var is in use, would we be able to find
>/
>>
>Do the various loaders permit an argument resembling
>"apr-util-1/bar.so" to consult the non-envvar loader configuration?
>
The apr-util's apu-prefix=/foo becomes /foo/lib/apr-util-1/ so this is
and
isn't addressed, and really can't be. Unless dlopen supports finding
these
'default' platform directories, we are at a loss.
>
>

In a non relocated installation, this really isn't a problem though
right? As long as the library remains in the path that the linker
initially was told it'd be at, this is a non issue, and one would expect
in a non SHLIB_PATH situation, that would be the case,

In a case where it is relocated, envvar just needs to be updated right?

Thanks,
Andy

William A. Rowe, Jr. wrote:
>
>In a case where it is relocated, envvar just needs to be updated right?
>
As a workaround, yes.
>
In the long term, we have to fix apr-util, really not httpd's problem,
to teach apr-util's apu_dso to hunt in each shlibpath dir and its
apr-1-config subdir.
>
As for traditional yet relocated builds, say with /bogus/path
and installed in /usr/lib, well that will require an envvar fixup
regardless.
>
Based on the comment that was attached to the bug I filed on this
there's an even easier option when configuring. I was
unaware this was disableable, but should have looked at the apr-util
configure

That seems to be the simplest solution for bindist or otherwise
relocated apr/apache builds.

Andy

William A. Rowe, Jr. wrote:
You can certainly do this; it reverts to apr-1.2 behavior.
>
Sadly, mainline packages are exactly what the dso option was added for.
When building httpd for the mass consumer, it's not possible to predict
which of 6 sql, 4 db and ldap modules they will actually use. The
combined
footprint of these at runtime is asinine.
I would think that in the case of a mainline package, the final
installation path would be predictable (at least if it's something like
a Linux distribution or something like that) so the apr-util-1 directory
would be the same as what it was configured/built for.
course; this is no different
that a typical monolithic php build, and loading both, apr-util dso will
save you little except for a few additional relocs since these libs were
already slurped in ;-)
Yeah, I think given the targeted use we bundle apache for the
"workaround" of using is really the solution for the
problem for us.

Thanks for the info and help,
Andy