You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Michael Felt <ma...@gmail.com> on 2012/03/02 01:55:11 UTC

APR and "portability" issues - /usr/include gets skipped by configure when apr is external

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
=======

Re: APR and "portability" issues - /usr/include gets skipped by configure when apr is external

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 6:55 PM, Michael Felt wrote:

> 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!

FWIW I've built APR on some 100 different combinations of OS major.minor
vs some dozen sun/intel/ibm/hp cpu architectures at one time or another.
AIX, HP/UX, Solaris, Linux, BSD, Darwin, Windows, etc etc etc.  Not BS2000,
and I'm missing a couple other esoteric, although I know it builds on those
from others folks experiences.

You need to get APR built, pay attention to ./configure output.  The only
AIX build I now deal with is xlc_r.

Then, you need to build APR-util, depending on APR, expat, various dbm and
and dbd providers, and recently openssl - which depends on zlib.

You'll only know if you are succeeding or failing by studying the ./configure
output, which should tell you what was detected and what detection failed.

APR is entirely portable.  It isn't our headache whether (in your example)
zlib is installed in a consistent way.  If you discover that a dependency
is not predictable you may need to create yet another dependency package.




Re: APR and "portability" issues - /usr/include gets skipped by configure when apr is external

Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Mar 1, 2012 at 7:55 PM, Michael Felt <ma...@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`