Dustin J. Mitchell --> amanda-users (2008-06-28 13:53:43 -0400):
> 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
                              ^^
I assume with "it" you mean the "local copy of the file", and not the
alloca.h "in the system" (which doesn't exist on my system), correct?


> 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.

Nice to hear :)

Hmm, what fix would you advise for 2.5? Sync the CFLAGS? (I want to
fix the Amanda package in [1]pkgsrc which is still at 2.5.)


> 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.

Thanks; you'll probably hear from me when I reconfigure my Amanda
systems to use Kerberos ;-)


Regards, Jukka

[1] http://www.pkgsrc.org/

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~