"Andrew L. Moore" <[email protected]> writes: > ACLOCAL_AMFLAGS = -I m4 > -SUBDIRS = libglibc libutil libparser libltdl plugin-factory > +SUBDIRS = libutil libparser libltdl plugin-factory > +if LDADD_GNULIB > + SUBDIRS += libglibc > +endif > if !USE_DB185_COMPAT
Please don't used the systems Gnulib package. They may be some version from 2013, as is the case of FreeBSD, or somewhat recent in the case of Fedora. Gnulib is meant to be used using the ./bootstrap script and a pinned git submodule or commit hash. Some projects decide to write their own script to 'git clone', checkout a certain commit, and do their own 'gnulib-tool' invocation. But that is more work, and not really needed. > One complication is that the function hash_string is no longer > included in Gnulib. > > 4. So the final patch is an attempt to address these issues in > minimalist (lazy) way: If the system provides regcomp and > getopt_long, then the system-provided functions are used by > default. To override this, use the configure option > `--with-included-regex'. An updated version of the hash_string > function by Bruno Haible is added directly to libutil/strhash.c. > The function is described in the article: > > https://www.haible.de/bruno/hashfunc.html > > A more correct approach might be to leverage Gnulib's bootstrap script > and update strhash.c to use current Gnulib hash functions. If I had > more time, I would have liked to offer an alternative patch for this. > The current Gnulib does have lots of overhead, so maybe the included > patch will be acceptable compromise. The same function is provided through the hash-string2 module, but named 'hash_pjw'. Collin
