Wednesday, December 30, 2015

Building 64-bit AIX Executables with Autotools

Creating 64-bit AIX executable is not quite as straight forward as in other platforms if you are using Autotools' Libtool. Actually, even if you don't use Autotools' Libtool, it would still be not really as straightforward as in other platform supported by GNU Autotools. I'm not going to present an example code that runs on AIX as 64-bit executable in this post. However, I'll show you how to build such program with the correct build script, with the assumption that you are using GNU Autotools.
Now, you've got the basics. Let's proceed to the real stuff. Below is the abridged version of the build script I use to build the debug version of my autotools project in AIX:

## NOTE:
## -----
## - Passing native linker flag via LDFLAGS worked as documented in libtool (as shown below). 
## - For more info on native AIX ar archiver, see: 
## - For more info on native AIX linker, see: 

case "$1" in 

      AIX) ./configure CFLAGS="-DDEBUG -fstrict-aliasing -Wstrict-aliasing=2 -g -O0 -maix64" \
    LDFLAGS="-Wl,-b64" AR='ar -X32_64' && make V=1

Mind you that I'm using libtool in the autotools project that uses the build script above. As you see, you need to pass the correct flags to the compiler (I'm using GCC on AIX), the linker and tools invoked by libtool (if you're using libtool). The -Wl flag is a libtool flag used for passing flags directly to the underlying linker. In this particular case, the linker is AIX native linker (see: AIX ld Command). The next thing to pay attention to is the ar archiver is AIX native archiver. This archiver only supports 32-bit object file by default. Therefore, you must explicitly override ar setting to force it to switch to support 64-bit object code, as shown above. See AIX ar command for more details on the archiver.

The release version of the build script is not that different from the debug version. I think you could figure it out already.

Hopefully this helps those working with Autotools projects in AIX.

Friday, December 25, 2015

The Importance of Reading Autoconf and Automake Manuals

The title of this post is possibly an understatement. However, time and again, silly questions and "stupid"/inappropriate way of using software tools can be prevented. This is especially applies to all GNU-related tools. If you've installed GNU tools such as Autotools, you must read its accompanying manual, preferably via:
$ info autoconf
$ info automake
Take your time to learn how to use keyboard navigation by pressing "?" key to enter the navigation help menu.

You'll appreciate the manuals better after seeing questions like this at Stackoverflow. Let me copy the relevant question here:
I've been looking for this for a while: I'm currently converting a medium-size program to autotools, coming from an eclipse-based method (with makefiles)
I'm always used to having a "debug" build, with all debug symbols and no optimizations, and a "release" build, without debug symbols and best optimizations.
Now I'm trying to replicate this in some way with autotools, so I can (perhaps) do something like:
make debug
Which would have all debug symbols and no optimizations, and where:
Would result in the "release" version (default)
PS: I've read about the --enable-debug flag/feature, ...
Well, this question is kind of "stupid" if you have read Automake manual. The manual explains the answer to such question in detail in section 2.2.6 Parallel Build Trees (a.k.a VPATH Builds), thorough an example. The title of section 2 of the manual is An Introduction to the Autotools. I think now you know where I'm getting at without going further.  I have to give kudos to William Purcell for his answers in that Stackoverflow thread.

Now, the unfortunate fact that many developers failed to see the value of reading the manual. The prove is everywhere, if you found a package that uses Autotools and provide a "./configure --enable-debug" flag which changes the compiler flags such as the optimization flag, then it's a sign of trouble because the "maintainer" of the code certainly doesn't follow GNU autotools philosophy in creating his package and make other people life harder. FYI, in GNU software terminology, the maintainer is one who create the software package, while user is one who compile and install the package.

Well, that's it for reminder to RTFM.