Building Apache 2.0.45 in AIX51 64 bits
This is about problems I have foud building Apache 2.0.45 in AIX 5.1 64 bits. First in all, when i build apache, i use a environment like this:
PATH=$AUTOTOOLS:$PATH
CC="xlc_r"
CXX="xlC_r"
CPP="xlC_r -E"
LDFLAGS="-blipath:/usr/lib:/lib"
CFLAGS="-q64 -I. -I/usr/vacpp/include -qstrict -qlanglvl=extended -D_LARGE_FILES -g -qfullpath"
LTFLAGS=" "
OBJEXT=".o"
LIBEXT=".so"
AR="/bin/ar"
AR_FLAGS="-rv"
RANLIB="/bin/ranlib -t -X64"
OBJECT_MODE=64
LIBPATH="/usr/lib:/lib"
Note i use autotools to create configure files, those delivered with apache don't work right
Well, next, i create a clean build system
cd $source_dir
./buildconf
I don't execute
build/binbuild.sh for to several reasons, as you can see below I need to change some things in middle of process... btw, apr and apr-util don't know Apache Layout, then, i usually set
LAYOUT=apr and
LAYOUT=apr-util in respective configures, just before
sed command use it.
Next, I modify server
core.c to apply a patch to solve a
xlc problem as describe by
Jeff Travick in
"Status of Apache 2.0 on AIX"
Then, depending on environment you have set, probably, you could build all, however, if you do that now, you will probably find some problems.
1. Where is
libexpat.so? nowhere, it won't generate
2. httpd won't import symbols
3. modules and apr-util libraries will have absolute paths in its loader sections
To solve this, I must after execute
configure manually, modify makefiles before make. So, I execute
configures:
cd $source_dir
./configure --enable-layout=Apache --prefix=$source_dir/bindist --enable-mods-shared=most \
--with-expat=$source_dir/srclib/apr-util/xml/expat --enable-static-support</tt>
1. Fix libexpat.so generation
srclib/apr-util/xml/expat/lib/Makefile changed:
...
install: $(LIBRARY) $(APIHEADER)
...
$(LIBTOOL) --mode=install cp $(LIBRARY) $(DESTDIR)$(libdir)
...
I usually use
libtool from
apr:
...
LIBTOOL = $(SHELL) $source_dir/srclib/apr/libtool
...
2. Fix httpd import symbols
To fix this, modify
build/config_vars.mk and set
HTTPD_LDFLAGS to get
httpd.exp file:
...
HTTPD_LDFLAGS = -bI:$my_source_dir/server/httpd.exp
...
3. Fix absolute path references in libraries
I really hate this, finding absolute path references in loader section of libraries after generating a kit:
$ dump -X64 -Hv libparutil-0.so
libaprutil-0.so:
...
***Import File Strings***
INDEX PATH BASE MEMBER
0 absolute_path:/usr/lib:/lib
1 absolute_path/bindist/lib libexpat.so
2 libiconv.a shr4_64.o
3 absolute_path/bindist/lib libapr-0.so
4 libc.a shr_64.o
Adding
-blibpath=/usr/lib:/lib to
LDFLAGS isn't sometimes enought to solve this. Sometimes,
libtool removes this flag. If configure generated
Makefiles with libraries full names in LIBS, or
libtool doesn't find libraries in .libs, it will search for it in another places and full paths will be generated
This problem mainly affect module libraries and
libapr-util.so, the trick to solve it is, i think, to give to
libtool flags in following way:
...
LDFLAGS=-L$source_dir/srclib/apr -L$source_dir/srclib/apr-util \
-L$source_dir/srclib/apr-util/xml/expat/lib -blibpath:/usr/lib:/lib
...
LDLIBS=-lapr-0 -laprutil-0 -lexpat
...
For modules, it could be enought modifying
build/config_vars.mk, for
apr-util, I didn't find the right place to properly fix it, so I dump libtool command to a log, then, after
make and
make install, I launch the xlc command manually, some like this:
xlc_r -o .libs/libaprutil-0.so.0.9.3 \
buckets/apr_buckets_file.o buckets/apr_buckets_pool.o buckets/apr_buckets_flush.o buckets/apr_buckets_refcount.o \
...
misc/apr_rmm.o misc/apr_reslist.o misc/apr_queue.o misc/apu_version.o strmatch/apr_strmatch.o xlate/xlate.o \
-L$source_dir/srclib/apr-util/xml/expat/lib/.libs -lexpat \
-L$source_dir/srclib/apr/.libs -lapr-0 \
-liconv -lm -lnsl -lc -Wl,-brtl -Wl,-bnoentry -Wl,-bexport:.libs/libaprutil-0.exp \
-Wl,-G -blibpath:/usr/lib:/lib
Something strange ...
make build
.so right, but
make install "relinks"
libaprutil-0.so (why?) taking other flags and producing a library with a wrong load header.
Another problem is about
mod_dav, after a proper build and install, I start
httpd and looks ok, but when i try to connect, a core is generated ... debugging, I have found that a request is arriving to mod_dav. This request isn't for mod_dav, probably, mod_dav was loaded too soon, or another module that would should have processed the request previously, hasn't done it. I have found two solutions for this.
1. Modifying
modules/dav/main/mod_dav.c
static int dav_fixups(request_rec *r)
{
dav_dir_conf *conf;
...
if (strcmp(r->handler, DAV_HANDLER_NAME) != 0) /* This is the fix, if program is allowed to continue */
return DECLINED; /* without this check, a core could be generated */
conf = (dav_dir_conf *)ap_get_module_config(r->per_dir_config,
&dav_module);
if (conf->provider == NULL) { /* This could become a core if conf isn't a valid pointer */
return DECLINED;
}
...
}
2. A colleague told me a different solution, this is to statically link mod_dav.a into mod_dav_fs.so, something like this:
xlc_r -o .libs/libmod_dav_fs.so.0.0.0 \
mod_dav_fs.o dbm.o lock.o repos.o ../main/.libs/libmod_dav.a \
-lc -Wl,-bnoentry -Wl,-bexport:.libs/libmod_dav_fs.exp -Wl,-G -blibpath:/usr/lib:/lib
... and, well, it is true,
httpd don't crash after this ... but I don't understand why this is done ... if we build a different provider, must we statically link
mod_dav too? ... I dont know if
mod_dav will work properly.
This is all, I have finally create several scripts to pack .tar.gz file in the usual way, taking parts from original
build/binbuild.sh, ... previously I copy sources to local directory in order to remove temporary .nfs files, taking care that my script sets original paths in
httpd-std.conf, in order to ensure a future proper execution of install-bindist.sh.
From Apache 2.0.39 (from bug in
core.c), I have seen that AIX have been forgotten by the community, I think that if Apache for AIX's build system isn't fixed now, the next apache versions could probably become too hard to build.