robert at linuxfromscratch.org
Sun Oct 12 07:54:58 PDT 2008
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev