apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: APR and "portability" issues - /usr/include gets skipped by configure when apr is external
Date Fri, 02 Mar 2012 01:27:06 GMT
On Thu, Mar 1, 2012 at 7:55 PM, Michael Felt <mamfelt@gmail.com> wrote:
> Call it innocence, call it naive, call it whatever - but APR is an obstacle
> to be overcome. There is documentation, but lacks an overview of what/how
> apr is used.
> X pages long list of variables does not help prepare one (read me if you
> will) for proper usage.
>
> CASE: built apr, apr-util, httpd on separate system. Want to verify process
> used to create build on another system. Unfortunately, apr has undefined
> variables so cannot build in second environment - install APR and APR-UTIL
> packaged in previous environment. Insert extra files in /usr/include same as
> on original system.
>
> Start configure - runs well until zlib is needed (copy files to
> /usr/include, per above and compile conftest.c successfully). Run configure
> again, still fails.
> My guess, after looking at the log output is that while /usr/include/zlib.h
> was found and used on the original system now "configure" is only using the
> /opt/include
> where the files are not located.
>
> Request: please think about the basic documentation - right now if you
> follow the documentation link the first page is one that seems to be "there
> is no documentation".
> The other navigation items show otherwise - but what are all these
> functions, modules, etc. And how do they explain that configure does not
> work.
>
> p.s. the first hint that something was wrong was the return of a static name
> for a compiler (was cc - xlc was better), but now working with gcc - so
> everything fails.
> -- I have learned that apr and apr-util are largely static - executable
> caching of variables - is that one way of describing how it works?
>
> Note: I have no idea of what is in libapr or libaprutil - but I am concerned
> that they are not going to be portable enough to use across different
> hardware/os platforms
> even those platforms are binary compatible. Also - maybe - the problems are
> limited to apr-1-config and apu-1-config. Here is hoping!
>
> Note: 6000-ibm-aix: bad number ... Is this because this is an AIX 7.1
> system? It moves on, thankfully, but thought this was the cause initially.
>
> ======
> ./configure[5865]: 6000-ibm-aix: bad number
> + cp conftest.c mytest.c
> + ac_fn_c_try_link 11027
> + print -r -- configure:11035: result: not found
> + 1>& 5
> + print -r -- not found
> + 1>& 6
> + enable_deflate=no
> + INCLUDES=-I$(top_builddir)/srclib/pcre -I. -I$(top_srcdir)/os/$(OS_DIR)
> -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) -I$(top_srcdir)/modules/http
> -I$(top_srcdir)/modules/filters -I$(top_srcdir)/modules/proxy
> -I$(top_srcdir)/include -I$(top_srcdir)/modules/generators
> -I$(top_srcdir)/modules/mappers -I$(top_srcdir)/modules/database
> -I/opt/include -I/usr/include/openssl/include
> + LDFLAGS=  -L/usr/include/openssl/lib
> + rm -f core conftest.err conftest.o conftest conftest.c
> + test x-lm  -lz = x-lz
> + apr_new_bugger=
> + apr_removed=0
> + test x-lm != x-lz
> + apr_new_bugger= -lm
> + test x-lz != x-lz
> + apr_removed=1
> + test 1 = 1
> + test x != xyes
> + echo   removed "-lz" from LIBS
> + LIBS= -lm
> + CPPFLAGS=
> + print -r -- configure:11066: checking whether to enable mod_deflate
> + 1>& 5
> + print -rn -- checking whether to enable mod_deflate...
> + 1>& 6
> + test no = no
> + test yes = no
> + as_fn_error mod_deflate has been requested but can not be built due to
> prerequisite failures 11072 5
> configure: error: mod_deflate has been requested but can not be built due to
> prerequisite failures
> + exit_status=1
> + 1>& 5
> =======

That's way too much to grok :)

What you're showing above is part of the httpd build, not part of apr.
 zlib isn't used by apr.  apr and apr-util are code -- networking,
management of private and shared memory, files, etc. -- but I guess if
you're having trouble building it the autoconf side may seem to be the
whole thing.

httpd uses some autoconf macros from APR and they use the "apr_" prefix.

This is the apr list, so why not take the opportunity to make sure apr
and apr-util are building as we expect...

apr 1.4.6:

CC=xlc_r ./configure --prefix=whatever && make && make install &&
make test

Proceed with apr-util 1.4.1:

Similar to the above, but point to your apr using the --with-apr
parameter to configure

Does that work on all your systems, substituting the desired compiler
front-end for xlc_r?  Do you need to try other configure arguments for
one reason or another?

I don't know about the AIX level support/that error message...  Does
this display something reasonable?

build/config.sub `build/config.guess`

Mime
View raw message