GNU Autotools Problems and Fixes

In the course of modifying an opensource source code recently, I found out that some GNU autotools (particularly automake and autoconf) "constructs" can cause compatibility problems. I'll explain two of them below.

First, the AC_CONFIG_HEADER construct.

Some macro extensions to the default Automake/Autoconf constructs uses the old AC_CONFIG_HEADER construct which has been superseded by AC_CONFIG_HEADERS in recent GNU autotools (in my case I'm using automake 1.10). Notice the change to plural form with addition of "S" in the end of the macro.

One particular annoying bug that I found is the widely used AX_PREFIX_CONFIG_H macro uses AC_CONFIG_HEADER in its older version (which is used in a lot of opensource project). Therefore, if you're migrating an old source code which uses this particular macro in its older incarnation, make sure you change the AC_CONFIG_HEADER macro to AC_CONFIG_HEADERS. Otherwise, automake will fail when you try to update the auto-generated Makefiles and the corresponding build scripts.

Second, the use of GNU make extension

Sometimes using GNU make extensions in Makefile.am file will cause portability warnings to be shown when you invoke automake. To prevent the warning those warnings, you can use the following construct:

AM_INIT_AUTOMAKE([-Wno-portability])

in your configure.ac/configure.in file.

Those are the most important things. Another rather important thing is updating the libtool-related scripts if the opensource source code uses libtool and you're actually migrating to newer autotools version from a very old one. It's as easy as invoking this:

me@my_machine:~/Projects$ libtoolize -c 

The "-c" switch instructs libtool to copy the libtool-related scripts instead of symlinking them. It's important to do so, to make sure the old libtool-related scripts updated accordingly and the new one will be included in the software package. This is especially important if you use some sort of Revision Control System (RCS) such as subversion, git or others.

That's it for now.

Combining GNU Autotools with Qt to One Build System

As you have probably aware, when you have a project that uses GNU Autotools (autoconf, automake, libtool) and Qt, there are two different build systems in use. First is the GNU autotools build system and the second is the Qt build system (Qmake, etc.).

The weakness of using two independent build system probably is not too obvious. However, when you start trying to build the whole project outside of the root directory of the source code, the build will fail. With GNU autotools itself, the build will be successful. Then how do you migrate from Qt build system to GNU autotools? It's simple, use Autotroll (http://tsunanet.net/autotroll/). Autotroll is a set of m4 file and makefile which will help you carry-out what qmake do. This way, the build system will be unified into GNU autotools build system. No more calls to qmake manually (or within a script you made).

Building Qt Application on 64-bit Multilib Systems

Some Qt application cannot build correctly on 64-bit multilib systems by default. For example, the Italc application (http://italc.sf.net). The problem is, the default search path for Qt library usually set to the 32-bit qt library whereas the default C++ (GNU g++) compiler is 64 bit one. To force the application build process to use the 64-bit Qt library, you must set the QTDIR environment variable to the path_to_64_bit_Qt_library. For example, in my machine this is how I build the Italc application:

darmawan@opunaga:italc-1.0.9$ QTDIR="/usr/lib64/qt" ./configure --prefix=/usr  --libdir=/usr/lib64
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
...

ICQ behind a proxy with pidgin

Using your ICQ account with Pidgin in network behind a HTTP proxy is not a straight forward matter. These are the settings which you should change on your ICQ account settings in Pidgin:
1. Change the Port in the Account|Modify Account|Advanced tab for the login.messaging.aol.com server from 5190 to 443.

2. Go to Account|Modify Account|Proxy tab and enter the correct host and port for your HTTP proxy. If the proxy needs an authentication, you should enter your username and password in that tab. Otherwise, leave the username and password blank.

That's it. Hopefully it solves your problem.