autotools and patches

Robert Connolly robert at
Wed Aug 30 21:40:16 PDT 2006

I'm lucky to have a job that allows me to daydream. I was thinking today, and 
so here is the resulting rant :-)

I think it would be a good idea to install autoconf, automake, libtool, and 
probably autogen too, in chapter 5 /tools, to allow us to autoreconf 
everything in chapter 6 chroot.

First, newer autoconf add newer gcc options, like -std=gnu99 to CC. It's not a 
major thing, but its nice.

Second, bugs like the ones in Gawk with LANGINFO_CODESET/LC_MESSAGES can be 
fixed properly by grabbing the latest from gawk-cvs(which 
doesn't seem to actually exist, but there's a newsgroup), instead of silly 
hacks to config.h. If these sorts of things are not already fixed upstream, a patch is likely to be accepted upstream. Bugs in m4 macros can 
also be fixed globally by reconfiguring every package... Owl Linux has a 
couple patches to fix warnings caused by conftest code in autotools.

Third (and best), patches to and are easier to 
maintain and far more likely to be accepted upstream. Our 
coreutils-suppress_uptime_kill_su patch is a good example. This patch needs 
to be re-diffed for every Coreutils release, and it will never end. The best 
way to not install these programs would be to add 
a --without-program=uptime,kill,su option to Some Linux 
distributions use some coreutils' programs and not others, so in the Linux 
community there must be a dozen hacks to Coreutils to solve basically the 
same problem. An autoconf/automake macro to disable the build/install of 
selected programs would allow every distribution to use the same patch. It's 
better for us because we would have ten times as many testers and auditors 
using the same patch, its far more likely to be accepted upstream, and the 
patch would not need to be re-diffed for every new Coreutils release. 
Autotool patches are also generally smaller and easier for administrators to 

Furthermore, as I mentioned a while ago it would be nice to have macros for 
warnings, ssp, fpie, fortify_source, and even mudflap, so they have configure 
switches to enable or disable them. Again these are far more likely to be 
accepted upstream if they are configured with autotools, especially now that 
these features are all in mainline GCC. The same way default_pic -fpic is 
detected in Glibc, default_ssp can be detected and -fno-stack-protector would 
be added by --disable-ssp... or -fstack-protector[-all] added 
by --enable-ssp, or the default to do neither. If accepted upstream, package 
maintainers (the folks who do the most debugging and auditing) would be more 
likely to find/fix problems which everyone else may have overlooked.

I'm just as guilty of making hacked patches as anyone else. Its a bit more 
work to add proper macros and scripts for autotools initially, but in the 
long run its less work.

And the last thing I thought about today was a patch policy for HLFS. I think 
it would be a good idea to make it obligatory for patches to be submitted 
upstream for review. Package maintainers can either accept, modify, or reject 
the patch. If it is accepted or modified, more people would be using the 
patch and it would withstand more testing and review (which is better for 
everyone). If the patch is rejected but still added to HLFS, we can add a url 
to the mail thread in the book so there is a documented explanation.

Again, I admit I'm as guilty as anyone, but the way our patches are made needs 
to change. Many of our patches are ugly hacks which have no prayer of ever 
being accepted, which leaves us to maintain them indefinitely, and leaves the 
Linux community to have a dozen patches to fix the same problem. I'm tired of 
participating in this amateur hacking and I'd like to start taking these 
things a little more seriously. I plan to patch every package to fix compiler 
warnings, and I want to get off on the right foot.

To start, an --enable-werror macro could be added to the autoconf package so 
its available to every package when they're reconfigured. Its a simple matter 
of copying the macro to m4/ and including it in aclocal.m4 for submition to 
package maintainers. The Autoconf macro archive at has lots good examples. After that, 
go one package at a time fixing warnings and fixing existing unsuitable 
patches. Unfortunately this will break HLFS even more than it is already, and 
put the first stable release even further in the future, however it will make 
the first stable release better.

I can't really see a disadvantage, other than the time consumption. Does 
anyone have reasons against adding autoconf, automake, and libtool to chapter 
5? I'd love to hear comments too, maybe there are issues I have overlooked.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list