Status of Apache 2.0 on AIX

Warning! This document hasn't been maintained in a long time!

Please use the httpd user's mailing list for help with Apache on AIX.

Software levels considered here

compilers

xlc: 5.0.2.3 or later, including 6.0; It is known to work when invoked as cc_r, xlc_r, and xlC_r.

5.0.2.0, 5.0.2.1, and 5.0.2.2 cannot be used with optimization (-O2) due to a compiler bug. There is another issue which still affects more recent levels of the compiler. See operational problem "O3" below.

gcc: I've used 2.95.2 on AIX 4.3.3

system software

AIX 4.3.3, 5.1, and 5.2

If you want IPv6 supported on AIX 4.3.3, make sure you are have at least ML-09.

In general, you shouldn't be far behind on maintenance, but other than the IPv6 issue, I'm not aware that a particular maintenance level is good or bad w.r.t. Apache 2.0. I ran 4.3.3 with no maintenance for ages with no problem other than getaddrinfo() issues which caused APR to disable IPv6 support.

Apache

Apache 2.0.36 or 2.0.39 or later GA Apache levels (2.0.45 or 2.0.44+patch needed for apxs+gcc to work)

other

GNU libtool 1.4.2 or 1.4.3

Don't even think about using any other version. If a newer one becomes available and it isn't mentioned here, and you've verified that it works fine, please notify Jeff Trawick.

Build flavors

64-bit and 32-bit

DSO and non-DSO

Known build issues

B6 - need to clean out prefix/lib before make install

On AIX, shared objects once loaded remain loaded even after the use count is decremented to zero. Thus, standard practice is to rm -f a library before relinking or copying over it. But libtool doesn't do that for us and neither does the Apache build, resulting in a pain in the behind when doing make install. Hopefully libtool can be tweaked?

Recommended work-around:

Manually remove files in prefix/lib before make install.

Alternately, run /usr/sbin/slibclean as root.

B14 - gcc-built httpd can't load some DSOs

[trawick@gorthaur httpd-2.0]$ ./httpd -t
Syntax error on line 18 of /home/trawick/apacheinst/conf/httpd.conf:
Cannot load /home/trawick/apacheinst/modules/mod_actions.so into
server:        0509-130 Symbol resolution failed for
/home/trawick/apacheinst/modules/mod_actions.so because:
        0509-136   Symbol __ashldi3 (number 15) is not exported from
                   dependent module lt-httpd.
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.

Recommended work-around:

After configuring but before running make, add the following three lines to the end of httpd-2.0/server/httpd.exp: 

__ashldi3
__ashrdi3
__floatdisf
The set of symbols required may vary among gcc versions and may also depend on the set of modules you are loading as DSOs. Please send me any information about alternate lists of gcc-specific symbols.

Another work-around is to statically enable the problematic module.

B16 - AIX make won't build APR test programs

For reasons unknown to me, $< is not expanded by AIX make when building mod_test.slo.

Recommended work-around:

Use GNU make for that subdirectory.

B17 - apxs+gcc doesn't build a DSO properly

Apache DSOs need to be linked with the -G option, but libtool doesn't currently know to add that when using gcc. (Strangely enough, it does know to add it when using xlc.) You can add -G manually by adding -Wl,-G to your apxs options, as in the following example: 
apxs -c -Wl,-G mod_mine.c
The issue is that Apache 2.0 and APR require that run-time linking is used, but without the -G run-time linking won't be used to resolve symbols required by the DSO. Thus, it will be unable to find APR/APR-UTIL symbols (and perhaps other symbols as well).

This has been fixed in 2.0.45-dev and 2.1-dev. You can apply this patch to 2.0.44 to avoid the problem: patch

B18 - AIX 5.1 ML 0 won't build a server that will load DSOs

Upgrade AIX if you're at ML 0 of 5.1 and Apache won't load any DSOs no way now how whether you used gcc or the IBM compiler. One user reported such a problem; I couldn't find any reason in dump output from httpd and the DSO; user upgraded the box to ML 5 and it started working without any problems. YMMV. You definitely don't need to upgrade to ML 5 to make it work. I can't promise that I ever used 5.1 prior to ML 1, and I never encountered such a hard failure.

Known operational problems

O2 - send_file() failure for 64-bit build on 32-bit kernel

send_file() is always returning EINVAL (at least on 5L; 4.3.3 is reported to have less consistent but still broken behavior). No apparent code change in Apache is appropriate (but you know how that goes :) ).

APR was changed 20030201 to disable sendfile support for 64-bit builds on AIX. This change should be in Apache 2.0.45+.

Recommended work-arounds for Apache < 2.0.45:

Remember: Only the 64-bit build of Apache is impacted, so you probably don't care about this.

Either of the following will avoid any problem with Apache:

O3 - xlc_r optimization problem with server/core.c

If using xlc_r and optimization, be sure to apply the patch at http://www.apache.org/dist/httpd/patches/apply_to_2.0.49/aix_xlc_optimization.patch. Without it, Apache won't be able to serve pages.

The problem is definitely present in vac.C 5.0.2.3 and 5.0.2.4. It is likely present in earlier levels.

If using CC=cc_r, you don't need the patch.

Items previously listed here that are now resolved