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.