No problem. Thank you! Regards, Shigio
On Tue, Oct 14, 2025 at 4:56 PM Andrew L. Moore <[email protected]> wrote: > > Please find attached a final, corrected, version of the patch > use-system-regex.diff. It works both with and without configure option > `--with-included-regex'. In Makefile.am, a TAB in front of > `SUBDIRS += libglibc' was causing the assignment to be rewritten as: > > .PRECIOUS: > > SUBDIRS += libglibc > > and thus never executed. Sigh. > > If an updated Gnulib were later added to the distribution, this patch > would still work as intended. Again, apologies not testing more > carefully before submitting. > > On 10/13/25 19:47, Shigio YAMAGUCHI wrote: > > Hello, > > I'll apply all of these patches. It may take a little time to adopt gnulib, > > but > > I will make it happen. > > > > Thank you for the very valuable patches! > > > > Regards, > > Shigio > > > > On Tue, Oct 14, 2025 at 8:06 AM Andrew L. Moore <[email protected]> wrote: > >> > >> We already have one vote in favor of importing Gnulib using its provided > >> bootstrap script. I am not opposed and merely offer the patch > >> use-system-gnulib.diff as a compromise. The patch name is actually > >> misleading, as I explained in reply to Colin Frank. Furthermore, I > >> complicated the patching process by providing the final patch, > >> ax_func_getopt_long.m4, in a different format: It fails to apply using > >> `patch -p1 <patchfile' as appropriate for the other patches. So I've > >> attached a new patch file, use-system-regexp.diff, that replaces both > >> use-system-gnulib.diff and ax_func_getopt_long.m4. This applies > >> correctly using `patch -p1'. Apologies for the complication. > >> > >> One note about Bruno Haible's hash function: In the version that is now > >> deprecated in Gnulib, hash_pjw, the final value is returned modulus the > >> key length, whereas in the original version included in this patch, no > >> modulus is taken (as was the case in the Compilers book). > >> > >> On 10/13/25 01:21, Andrew L. Moore wrote: > >>> The patch use-system-gnulib.diff depends upon an m4 macro which was > >>> omitted. Please find attached a patch for it below. > >>> > >>> On 10/13/25 01:07, Andrew L. Moore wrote: > >>>> Please find attached patches that allow building GNU Global v6.6.14 on > >>>> Fedora GNU/Linux v42 and v43. The first three are straight forward: > >>>> > >>>> 1. When looking for Universal Ctags, use option `--extras'. The code > >>>> does this, but configure was using `--extra'. > >>>> > >>>> 2. When looking for libsqlite3, add /usr/lib64 to the search path. > >>>> > >>>> 3. Address a GNU C v15 compilation error: assignment from incompatible > >>>> pointer type 'int (*)(void)'. The fix is to conditionally add > >>>> prototypes to dberr masks. > >>>> > >>>> Many modern systems come with Gnulib. So either GNU Global could link > >>>> against the system Gnulib, or, alternatively, the Gnulib `bootstrap' > >>>> script could be added to the GNU Global distribution. Gnulib bootstrap > >>>> downloads Gnulib modules as needed. See: > >>>> > >>>> https://cgit.git.savannah.gnu.org/cgit/gnulib.git/tree/top/bootstrap > >>>> > >>>> 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. > > > > > > -- Shigio YAMAGUCHI <[email protected]> PGP fingerprint: 26F6 31B4 3D62 4A92 7E6F 1C33 969C 3BE3 89DD A6EB
