Got it, thanks for the advice. I use the latest packages and try not to tinker too much.
Regards, Shigio On Tue, Oct 14, 2025 at 9:24 AM Collin Funk <[email protected]> wrote: > > "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 > -- Shigio YAMAGUCHI <[email protected]> PGP fingerprint: 26F6 31B4 3D62 4A92 7E6F 1C33 969C 3BE3 89DD A6EB
