Onward branch

Robert Connolly robert at linuxfromscratch.org
Fri Oct 10 18:57:21 PDT 2008

On Wednesday October 8 2008 04:02:09 am Robert Connolly wrote:
> Coreutils insists on using asprintf from gnulib, including
> ignoring --cache-file=config.cache, and its causing a million warnings, and
> not using asprintf from Glibc. I pulled my hair out trying to fix this, and
> it didn't help. The M4 package has the same problem.

m4/gnulib-comp.m4 in the M4 and Coreutils source, then run autoreconf, they 
both build with Glibc's asprintf() (with buffer checking).

The patch is big and messy at 138K for Coreutils, and this is a hackish 
workaround, but its the only thing I have found that works.

I prefer to just run autoreconf in the book, instead of patches. This means 
installing a full Perl to /tools, which is becoming more practical since 
Coreutils keeps needing more Perl modules, and installing Autoconf and 
Automake to /tools, so autoreconf is available for Coreutils on the final 
system. I prefer this because the Sed command for removing gl_FUNC_VASPRINTF 
from m4/gnulib-comp.m4, and the autoreconf, should work on other packages 
affected with this issue.

Ignoring the 'asprintf redefined' warnings means the package is using its own 
asprintf() (from gnulib), which has no buffer checking. So far I haven't seen 
this affect other library functions, but it might.

It might be a good idea to go through gnulib and find all the library 
functions provided by Glibc, and remove them all from every package using 
gnulib. Assuming they're compatible versions (posix compliant), the Glibc 
version should always be a better choice, because Glibc does heap and buffer 
checking the gnulib does not. With this asprintf() issue, we shouldn't assume 
that ./configure will properly decide that our libc already has the library 

And then to complicate things, autoreconf should be done on Coreutils and M4 
in the temporary tools, so the rebooted system is completely hardened. This 
either adds a host dependency for autoreconf, or moves Perl/Autoconf/Automake 
ahead of Coreutils when building the temporary system. This is a pretty major 
change just to work around this bug, but I suspect this bug will be around 
for a very long time... until gnulib detects library functions, even when 
they're macros (when _FORTIFY_SOURCE is defined), with 100% accuracy.

I like to look at these sorts of things as opportunities and blessings, to 
make the temporary and final system better, and not as a plague. I also find 
it funny how such a small thing as a redefined function warning could lead to 
such a change.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20081010/a3f7a8cf/attachment.sig>

More information about the hlfs-dev mailing list