Older blog entries for oku (starting at number 0)

I have a love/hate relationship with autoconf/automake... it is somehow cool for detecting libraries and stuff, it also may make cross compiling easier if done correctly. But it can also cause lots of trouble, even if done correctly:

I have autoconf'ed a small package I am currently developing, and it was all fine, it works, I built a Debian package of it, tested and was happy. I did this on a sid box. But it will be really used on a woody box, so I backported the package for woody, in a chroot, with autoconf and automake installed. I know that during build of a Debian package autoconf/automake should not be used, but just ./configure. But, for some reason during the configure stage autoconf is called, finds that the configure.ac is for autoconf 2.58 and fails... so why is this necessary? I tried different things, like putting another version number to AC_PREREQ, but autoconf 2.53 wants some other details differently, so that did not work out. Final solution is to uninstall autoconf in the chroot.

So autoconf does exactly the contrary to what it is intended for: to find out the environment a package is built in and configure the package accordingly. But fails miserably when it finds an old version of itself.

BTW, the same thing happened to me when I tried to backport flow-tools. Uninstalling the auto tools finally helped.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!