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.
If I remove gl_FUNC_VASPRINTF_POSIX, and gl_FUNC_VASPRINTF, from
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
Size: 197 bytes
Desc: not available
More information about the hlfs-dev