Problem determination for Apache build problems on AIX

Please be familiar with the following related documents:

Information in those documents will help you avoid certain types of build problems and allow you to avoid configurations which are known to be broken.

Introduction and disclaimers

Certain problems can occur when building Apache 2.0 for AIX which can result in initial load failures or failures to load Apache DSO modules or even segfaults. This document describes standard procedures for gathering the information needed to help determine the cause.

This is not part of the Apache 2.0 documentation. This is not a statement of Apache Software Foundation or Apache HTTP Server Project or even anybody really important.

Initial diagnosis

Did a load fail of httpd or a DSO module fail? Did a segfault occur when httpd tried to call an apr_ routine or when aprutil tried to call apr? If so, see Symbol resolution failures below.

Symbol resolution failures

Checking which libtool

Make sure you have libtool the right libtool and that it was built properly. There are some hints at this page. Pay particular attention to the special emphasis on -Wl,-bexpall.

Save the output from these commands:

which libtool
libtool --version
./buildconf | tee buildconf.out

(Run buildconf from the httpd-2.0 directory.)

Also, sanity-check that you are using the libtool you thought you were.

Checking executables and shared libraries for symbols

dump -Tv is our friend or analyzing why a symbol isn't resolved.

The following shows a few different types of symbols described in a dump of httpd:

(under construction)

The following shows a few different types of symbols described in a dump of an Apache DSO module:

(under construction)

The following shows a few different types of symbols described in a dump of libaprutil.a:

(under construction)

The following shows a few different types of symbols described in a dump of libapr.a:

(under construction)

Notice how the DSO module expects to resolve the function apr_file_open() from libapr.a(libapr.so.0) and the function ap_hook_error_log() from the main executable ("."). Notice how libaprutil expects to resolve the function apr_file_open() from libapr.a(libapr.so.0).

If you don't see the same exact symbol resolution in your build, it is doomed to fail and you should provide the output files created by the commands below (under Documentation).

Documentation

which libtool > /tmp/libtool.out
libtool --version >> /tmp/libtool.out
make extraclean     (okay if this fails)
./buildconf | tee /tmp/buildconf.out
LTFLAGS=' ' ./configure (your options) | tee /tmp/configure.out
make | tee /tmp/make.out
rm -f (your prefix)/lib/* (your prefix)/modules/*
make install | tee /tmp/make_install.out
dump -Tv (your prefix)/bin/httpd > /tmp/httpd.dump
dump -Tv (your prefix)/lib/libapr.a > /tmp/libapr.dump
dump -Tv (your prefix)/lib/libaprutil.a > /tmp/libaprutil.a

Also, create dump output for any DSO modules you're having problems with.

Also (as if that weren't enough), provide the versions of httpd.exp, apr.exp, and aprutil.exp which were installed in (your prefix)/lib and (your prefix)/modules.