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 function. 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. robert
pgpv5bLr66BtQ.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
