On Sat, Jun 28, 2008 at 1:05 PM, Jukka Salmi <[EMAIL PROTECTED]> wrote: > I'm not familiar with the autotools and with m4, but AFAICT the source > of this problem is in config/gnulib/alloca.m4. The resulting `configure' > script unconditionally defines HAVE_ALLOCA_H which is obviously wrong.
Actually, it's not quite "wrong." Gnulib is a little weird. What the rest of that macro does is to *check* for alloca.h, and if it's not found in the system, create a local copy of the file. I think that the compiler wasn't finding it because the amflock tests didn't provide all of the CFLAGS that are eventually present when source files are actually compiled. This was one of a few places in the configure script that used the rather unorthodox technique of compiling full *.c files, rather than constructing minimal "conftest.c" files directly (the normal technique). This was part of the reason that this code was replaced in 2.6.0. > This code seems to be in 2.6 as well. True. A few points there: 1. This problem won't recur in 2.6.0 because configure won't try to build any files that #include <amanda.h> during the configure process. 2. We don't use alloca() in the Amanda codebase, so I've added a ticket to remove the #include from amanda.h. 3. Gnulib's vasnprintf *does* use alloca, so the gnulib m4 and source files will remain in the codebase. I don't think this will cause a problem due to point 1. Nice job investigating this, by the way! If you want to stick around and hack on Amanda, we'd love to have you. Dustin -- Storage Software Engineer http://www.zmanda.com