Onward branch

Robert Connolly 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 
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


-------------- 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/20081012/abe117c7/attachment.sig>


More information about the hlfs-dev mailing list