On Sat, Jun 28, 2008 at 1:05 PM, Jukka Salmi <j+amanda AT 2008.salmi DOT ch> 
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