Hello,
thanks for your report.

First of all, to try the simple way: What happens when you just use a released tarball with a (./configure && make) as INSTALL says, without rerunning any of the autotools?

Replying to [ticket:33 pt158]:

{{{

aclocal && automake --add-missing && autoconf && ./configure && make

/usr/local/share/automake-1.14/am/library.am: warning: 'src/liblib.a': linking libraries using a non-POSIX
/usr/local/share/automake-1.14/am/library.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
}}}
True, fixed in the repo.

{{{
Makefile.am:38: while processing library 'src/liblib.a'
gnulib/lib/Makefile.am:33: error: @ALLOCA@ used but 'ALLOCA' is undefined
gnulib/lib/Makefile.am:33: The usual way to define 'ALLOCA' is to add 'AC_FUNC_ALLOCA'
gnulib/lib/Makefile.am:33: to 'configure.ac' and run 'autoconf' again.
}}}
This is strange; gl_INIT should pull in gl_FUNC_ALLOCA which does require AC_FUNC_ALLOCA; and
./configure as generated does include an @ALLOCA@ substitution.

I don’t know what is going on exactly, but I wouldn‘t be surprised if the gnulib files depended on particular versions of autotools, so rerunning some of the autotools without running all of them and without updating gnulib might be surprising. In any case the above chain might be a starting point for an investigation.

Following the recommendations and adding both "AC_FUNC_ALLOCA" and "AM_PROG_AR" to configure.ac leads to:
{{{
string.h.in contains the AC-Macro "@GNULIB_MEMMEM@" at the indicated position.
}}}
Another indication that gnulib and autotools don‘t quite play well together.

Removing the gnulib-directory and linking the gnulib from the ports-collection leads to the following error:
I would have about no expectations of that working without a very deep understanding of gnulib (deeper than needed to diagnose the above failures), which I currently don’t have. Also note that mlocate has to use a GPLv2 version of gnulib, i.e. not the lasest one.

Using mlocate checked out from mercurial leads to:

{{{

aclocal && automake --add-missing && autoconf && ./configure && make

Please see the HACKING file for the necessary steps to prepare a checkout for building.

Hi, thanks for the quick answer!

Using a released tarball leads to:

{{{
cc -I. -I./src -I./gnulib/lib -I./gnulib/lib -DDBFILE='"/usr/local/var/mlocate/mlocate.db"' -DLOCALEDIR='"/usr/local/share/locale"' -DGROUPNAME='"mlocate"' -DUPDATEDB_CONF='"/usr/local/etc/updatedb.conf"' -I/usr/local/include -g -O2 -Wall -W -Wcast-align -Wmissing-noreturn -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -MT src/src_updatedb-updatedb.o -MD -MP -MF src/.deps/src_updatedb-updatedb.Tpo -c -o src/src_updatedb-updatedb.o test -f 'src/updatedb.c' || echo './'src/updatedb.c
src/updatedb.c:39:10: fatal error: 'mntent.h' file not found

include <mntent.h>

     ^

}}}

Using the method described in HACKING:

{{{

../gnulib/gnulib-tool --import

[...]

hg revert --all

reverting gnulib/lib/stat-time.h

autoreconf -is

[...]
gnulib/lib/Makefile.am:33: error: @ALLOCA@ used but 'ALLOCA' is undefined
gnulib/lib/Makefile.am:33: The usual way to define 'ALLOCA' is to add 'AC_FUNC_ALLOCA'
gnulib/lib/Makefile.am:33: to 'configure.ac' and run 'autoconf' again.
autoreconf-2.69: automake failed with exit status: 1
}}}

After adding AC_FUNC_ALLOCA again, it ends in the empty #if in string.h.

Replying to [comment:2 pt158]:

Hi, thanks for the quick answer!

Using a released tarball leads to:

{{{
src/updatedb.c:39:10: fatal error: 'mntent.h' file not found

include <mntent.h>

     ^

}}}

That would be #15 (with an unfinished patch).

Using the method described in HACKING:

{{{

../gnulib/gnulib-tool --import

[...]

hg revert --all

reverting gnulib/lib/stat-time.h

autoreconf -is

[...]
gnulib/lib/Makefile.am:33: error: @ALLOCA@ used but 'ALLOCA' is undefined
gnulib/lib/Makefile.am:33: The usual way to define 'ALLOCA' is to add 'AC_FUNC_ALLOCA'
gnulib/lib/Makefile.am:33: to 'configure.ac' and run 'autoconf' again.
autoreconf-2.69: automake failed with exit status: 1
}}}

So this autotools problem does need to be resolved even in order to get the patch in #15 finished; I’m afraid it’s extremely unlikely I would have time to examine this in detail on FreeBSD in the foreseeable future.