I found another way to fix asprintf in M4, by using -D_GNU_SOURCE asprintf() gets used by test-vasprintf-posix.c and the test passes.
It works manually with Coreutils's test-vasprintf-posix.c, but ./configure still insists that we don't have asprintf in libc. I'll keep looking for a fix. robert On Friday October 10 2008 09:57:21 pm Robert Connolly wrote: > 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
pgpIyxMEI5EEa.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
