Re: help in deciphering a gnulib-tool/bootstrap issue

[Eric Blake]

On 05/04/2011 09:55 AM, Eric Blake wrote:
> On 05/04/2011 09:47 AM, Bruno Haible wrote:
>> Hi Eric,
>>
>>> once I update to the very next commit,
>>> 7ec62f74 (gnulib-tool: Reduce code duplication.), I start getting these
>>> messages when trying to bootstrap:
>>>
>>> ./bootstrap: aclocal -I m4 --force -I 'gnulib/m4'  ...
>>> missing file gnulib/tests/fseeko.c
>>> configure.ac:80: error: expected source file, required through 
>>> AC_LIBSOURCES, not found
>>
>> Oops, that commit looked safe. Apparently it isn't.
> 
> Aargh - I may be pointing the finger at the wrong commit.  Looking back
> at my logs, I'm now not sure whether it was the gnulib-tool change or
> the commit 096d7e(fclose: don't fail on non-seekable input) where the
> error first started appearing.

The gnulib-tool changes are exonerated.  After re-running my tests, and
being more careful about reading my logs, I have pinpointed the blame to:

0fc0aa38 (exit: drop remaining clients) - passes
001e7d63 (fclose: reduce dependencies) - fails

After the ./gnulib-tool portion of bootstrap, the failing version has:
gnulib/lib/fseeko.c
gnulib/m4/fseeko.m4
nothing in tests
and autoconf --trace AC_LIBSOURCES (after touching a dummy
gnulib/tests/fseeko.c to let things proceed) produced:
configure.ac:80:AC_LIBSOURCES:alloca.c
configure.ac:80:AC_LIBSOURCES:inet_ntop.c
configure.ac:80:AC_LIBSOURCES:getpass.c
configure.ac:80:AC_LIBSOURCES:inet_ntop.c
configure.ac:80:AC_LIBSOURCES:inet_pton.c
configure.ac:80:AC_LIBSOURCES:rawmemchr.c
configure.ac:80:AC_LIBSOURCES:stpcpy.c
configure.ac:80:AC_LIBSOURCES:strsep.c
configure.ac:80:AC_LIBSOURCES:uname.c
configure.ac:80:AC_LIBSOURCES:error.h, error.c


whereas the passing version had:
gnulib/lib/fseeko.c
gnulib/m4/fseeko.m4
nothing in tests
configure.ac:80:AC_LIBSOURCES:alloca.c
configure.ac:80:AC_LIBSOURCES:inet_ntop.c
configure.ac:80:AC_LIBSOURCES:getpass.c
configure.ac:80:AC_LIBSOURCES:inet_ntop.c
configure.ac:80:AC_LIBSOURCES:inet_pton.c
configure.ac:80:AC_LIBSOURCES:rawmemchr.c
configure.ac:80:AC_LIBSOURCES:stpcpy.c
configure.ac:80:AC_LIBSOURCES:strsep.c
configure.ac:80:AC_LIBSOURCES:uname.c
configure.ac:80:AC_LIBSOURCES:error.h, error.c

But those are identical, so it must be something else.  Next, I tried
tracing these macros.

Pre-patch:
$ autoconf --trace gl_FUNC_FSEEKO --trace gl_REPLACE_FSEEKO \
  --trace gl_REPLACE_FCLOSE --trace gl_FUNC_FFLUSH \
  --trace gl_REPLACE_FFLUSH --trace m4_syscmd:\$0
configure.ac:80:gl_REPLACE_FCLOSE:
configure.ac:80:gl_FUNC_FFLUSH:
configure.ac:80:gl_REPLACE_FFLUSH:
configure.ac:80:gl_REPLACE_FSEEKO:
configure.ac:80:gl_FUNC_FSEEKO:
configure.ac:80:gl_REPLACE_FSEEKO:
configure.ac:80:gl_REPLACE_FSEEKO:
m4_syscmd
m4_syscmd

Post-patch:
$ autoconf --trace gl_FUNC_FSEEKO --trace gl_REPLACE_FSEEKO \
  --trace gl_REPLACE_FCLOSE --trace gl_FUNC_FFLUSH \
  --trace gl_REPLACE_FFLUSH --trace m4_syscmd:\$0
configure.ac:80:gl_REPLACE_FCLOSE:
configure.ac:80:gl_FUNC_FSEEKO:
configure.ac:80:gl_REPLACE_FSEEKO:
configure.ac:80:gl_REPLACE_FSEEKO:
m4_syscmd
configure.ac:80:gl_FUNC_FFLUSH:
configure.ac:80:gl_REPLACE_FFLUSH:
configure.ac:80:gl_REPLACE_FSEEKO:
m4_syscmd

Hmm, notice that gl_FUNC_FSEEKO and gl_FUNC_FFLUSH swapped positions
(the m4_syscmd provides a nice indication of where gl_INIT swaps over
from lib files over to test files).  That is, the relaxation of fclose
dependencies changed fflush from mandatory to test-only, but in the
process, made it so that gl_REPLACE_FSEEKO is called while servicing the
wrong directory.

So, one trick is to make the various gl_REPLACE_* functions one-shot -
once a function has been replaced, then it shouldn't need replacing
again (where the second call might be an attempt to do a second
replacement in a test directory).

diff --git i/m4/fseeko.m4 w/m4/fseeko.m4
index 76507d1..eb5f2f3 100644
--- i/m4/fseeko.m4
+++ w/m4/fseeko.m4
@@ -52,6 +52,9 @@ AC_DEFUN([gl_REPLACE_FSEEKO],
   AC_LIBOBJ([fseeko])
   dnl If we are also using the fseek module, then fseek needs
replacing, too.
   m4_ifdef([gl_REPLACE_FSEEK], [gl_REPLACE_FSEEK])
+  dnl Once we have replaced the macro in the libs directory, we don't
+  dnl need to replace it in the tests directory
+  m4_pushdef([gl_REPLACE_FSEEKO])
 ])

 dnl Code shared by fseeko and ftello.  Determine if large files are
supported,

Should we do that to all the gl_REPLACE_* functions?

Another trick is to relax fflush to LGPL, then make fclose depend on
fflush.  And hey, we just happen to have a thread talking about that :)
 However, that feels like it is just papering over the issue, and that
some other dependency chain in the future will also repeat the issue.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature