Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Building Components on AIX

In December 2007, I (cat) spent a lot of time getting various VDT components to build on AIX 5.3. Below are some notes and suggestions that came out of my experiences.

Compiler commands

It seems like there are many different executables for the IBM compiler, but really there is just one compiler with some aliases that provide different configuration settings. The basic C compiler is xlc. The xlc_r executable runs the same compiler, but with settings for building threaded code (“r” stands for “relocatable”?). The basic C++ compiler is xlC and there is an xlC_r. This page summarizes those and other aliases nicely, or there is the IBM manual itself.

We agreed to try to use the “_r” versions whenever possible, so always start by using them (see below) and fall back to the plain ANSI ones when needed.

NMI prereqs

Be sure to set AIX-specific prereqs in the NMI cmdfile. To do so, you need to figure out which compilers the configure script (or, more generally, the build) will need. There’s no easy recipe for this step — check the documentation, look at a previous build, run the configure script manually, etc. Once you know which compilers are needed, add a line like this to the cmdfile:

prereqs_ppc_aix_5.3 = vac-6, vacpp-6

where vac-6 is for the C compiler (Visual Age C) and vacpp-6 is for the C++ compiler. If you don’t need one, omit it.

Select the IBM compiler

In most cases, you must go out of your way to force a configure script to use the IBM compiler(s) instead of gcc/g++. Fortunately, most configure scripts accept command-line switches to set the compiler. Here is a typical code fragment that I used:

my $configure_command = "./configure --prefix=$INSTALL_DIR";

# Use IBM compiler
if ($ENV{NMI_PLATFORM} =~ /_aix_/) {
    $configure_command .= " CC=xlc_r CXX=xlC_r";
}

system($configure_command);

This approach sets the compiler flags at the end of the command line. However, some configure scripts do not recognize them there. Instead, you must use the Bourne shell syntax for setting environment variables before a command:

my $configure_command = "./configure --prefix=$INSTALL_DIR";

# Use IBM compiler
if ($ENV{NMI_PLATFORM} =~ /_aix_/) {
    $configure_command = "CC=xlc_r CXX=xlC_r $configure_command";
}

system($configure_command);

I prefer the former approach, when possible, but mostly for aesthetic reasons. I think the latter approach may work in all cases.

OpenSSL

If the build requires OpenSSL, there is a trick to getting the NMI prereq to work with the IBM compilers. The OpenSSL prereq was built with the gcc compiler and has static link dependencies on the libgcc.a that comes with gcc. You must tell the configure command to look for OpenSSL and libgcc.a:

my $configure_command = "./configure --prefix=$INSTALL_DIR";
if ($ENV{NMI_PLATFORM} =~ /_aix_/) {
    chomp(my $gcc_lib = `gcc -print-libgcc-file-name`);
    chomp(my $gcc_lib_dir = `dirname $gcc_lib`);
    $configure_command .= " --with-ssl=/prereq/openssl-0.9.8e CC=xlc_r LDFLAGS=-L$gcc_lib_dir LIBS=-lgcc";
}

Also, don’t forget to declare the OpenSSL prereq. We only declare the prereq for AIX, because we want the default OpenSSL on other platforms.

prereqs_ppc_aix_5.3 = vac-6, openssl-0.9.8e

Check the results

No matter how carefully you construct your configure command, it may not work the way you expect. Always skim through the output from configure and possibly the build itself to see whether it seems to be doing the Right Thing™.

sed

The Globus build failed when it used GNU sed 4.1.4. It got errors like this:

sed: -e expression #1, char 34: Memory exhausted

It turns out that sometimes sed tries to allocate zero bytes of memory. On Linux that works fine--you get back a non-null pointer. However, there is no requirement that a zero-byte allocation gives you a non-null pointer. On AIX, allocating zero bytes gives you a null pointer. Apparently this causes GNU sed to fail.

I found a patch for it at http://www.mail-archive.com/gentoo-alt@lists.gentoo.org/msg02038.html

I tested the patch, compiled it with xlc_r, and it worked for me. The patch looks like this:

--- sed-4.1.4/lib/regex_internal.c.orig	2006-08-09 11:38:58.387831000 +0200
+++ sed-4.1.4/lib/regex_internal.c	2006-08-09 11:38:03.337832000 +0200
@@ -883,6 +883,9 @@
      re_node_set *set;
      int size;
 {
+  if ( size == 0 )
+    return REG_NOERROR;
+
   set->alloc = size;
   set->nelem = 0;
   set->elems = re_malloc (int, size);