Re: Patches for Fedora 42 & 43

2025-10-18 Thread Collin Funk
"Andrew L. Moore"  writes:

> Collin can correct me, but one way that using Gnulib's bootstrap
> script makes life easier is in avoiding header conflicts: when Gnulib
> is distributed as an integral part of a package, to _not_ build
> against it requres hiding the Gnulib headers. In the case of GNU
> Global, this can be done by excluding -I${top_srcdir}/libglibc from
> AM_CPPFLAGS (one of the omissions in my latest patch), but in the more
> general case, the Gnulib headers have to be renamed, which gets
> complicated fast.

I've never tried that. I would recommend using Gnulib's overriden
standard headers though. We test them on many platforms. And it allows
you to write code similar to if you were on a glibc system.

Take the following code:

while (getopt (argc, argv, shortopts) != -1)
  {
/* Process arguments.  */
  }

On a glibc system the preprocessed code will be the same. On a system
that does not permute argv so that nonoptions are at the end, it will
preprocess to:

while (rpl_getopt (argc, argv, shortopts) != -1)
  {
/* Process arguments.  */
  }

Pretend we are compiling 'cp' from Coreutils, this allows us to run the
following command:

$ cp COPYING LICENSE -p

Even if the system's 'getopt' function does not permute the arguments
internally.

Collin



Re: Patches for Fedora 42 & 43

2025-10-18 Thread Andrew L. Moore
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.


ax_func_getopt_long.m4
Description: application/m4


Re: Patches for Fedora 42 & 43

2025-10-17 Thread Andrew L. Moore
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 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.
diff --git a/Makefile.am b/Makefile.am
index 44452dc..6bbf764 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,7 +11,10 @@
 # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
 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
 SUBDIRS += libdb
 endif
diff --git a/configure.ac b/configure.ac
index 25e57ce..bf9eed1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,6 +25,7 @@ AC_INIT([GNU Global],[6.6.14])
 AC_DEFINE(COPYRIGHT_YEAR,["1996-2024"],[Copyright Year])
 AC_CONFIG_SRCDIR(global/global.c)
 AC_CONFIG_HEADERS([config.h:config-h.in])
+AC_CONFIG_LIBOBJ_DIR([libglibc])
 AC_CONFIG_MACRO_DIRS([m4])
 AC_PREREQ(2.71)
 AM_INIT_AUTOMAKE([1.9.3 gnu subdir-objects])
@@ -220,7 +221,39 @@ AC_ARG_WITH(db185-compat,
 ],[ with_db185_compat=no ])
 AM_CONDITIONAL([USE_DB185_COMPAT], [test "$with_db185_compat" != no])
 
-LDADD='../libparser/libgloparser.a ../libutil/libgloutil.a '$DBLIBRARY' ../libglibc/libgloglibc.a'
+LDADD='../libparser/libgloparser.a ../libutil/libgloutil.a '$DBLIBRARY
+
+AX_FUNC_GETOPT_LONG
+
+AC_MSG_CHECKING([whether included regex is requested])
+AC_ARG_WITH([included-regex],
+  [AS_HELP_STRING([--with-included-regex],
+[use included GNU regex library])],
+[], [with_included_regex=check])
+AC_MSG_RESULT([$with_included_regex])
+if test ! ."$with_included_regex" = .'yes'; then
+AC_CHECK_FUNCS([regcomp],
+  [with_included_regex=no],
+  [with_included_regex=yes
+   AC_MSG_WARN([System regex not found, falling back to included version])])
+fi
+AM_CONDITIONAL([LIBADD_REGEX],
+[test ."$with_included_regex" = .'yes' \
+   -o ."$ac_cv_func_getopt_long" != .'yes'])
+AM_COND_IF([LIBADD_REGEX],
+  [LDADD="$LDADD ../libglibc/libgloglibc.a"
+   AC_DEFINE([HAVE_REG_SYNTAX_T], [1],
+[Define to 1 if regex.h defines `reg_syntax_t'.])],
+  [AC_CHECK_TYPES([reg_syntax_t],
+[AC_DEFINE([HAVE_REG_SYNTAX_T], [1],
+  [Define to 1 if regex.h defines `reg_syntax_t'.])],[],
+  [[#include 
+#include ]])])
+
+AM_CONDITIONAL([LDADD_GNULI

Re: Patches for Fedora 42 & 43

2025-10-17 Thread Shigio YAMAGUCHI
No problem. Thank you!

Regards,
Shigio

On Tue, Oct 14, 2025 at 4:56 PM Andrew L. Moore  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  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  >> 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 
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB



Re: Patches for Fedora 42 & 43

2025-10-17 Thread Andrew L. Moore
Collin can correct me, but one way that using Gnulib's bootstrap script 
makes life easier is in avoiding header conflicts: when Gnulib is 
distributed as an integral part of a package, to _not_ build against it 
requres hiding the Gnulib headers. In the case of GNU Global, this can 
be done by excluding -I${top_srcdir}/libglibc from AM_CPPFLAGS (one of 
the omissions in my latest patch), but in the more general case, the 
Gnulib headers have to be renamed, which gets complicated fast.


On 10/13/25 22:03, Collin Funk wrote:

Shigio YAMAGUCHI  writes:


Got it, thanks for the advice.
I use the latest packages and try not to tinker too much.


No problem. Let me know if you need help. I am a committer in Gnulib. Or
you can send mail to [email protected].

I don't know CVS that well, though. So that will slow me down a bit. :)

Collin





Re: Patches for Fedora 42 & 43

2025-10-14 Thread Andrew L. Moore

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




diff --git a/Makefile.am b/Makefile.am
index 44452dc..04b6514 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,7 +11,10 @@
 # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
 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
 SUBDIRS += libdb
 endif
diff --git a/configure.ac b/configure.ac
index 25e57ce..6c9f9c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,6 +25,7 @@ AC_INIT([GNU Global],[6.6.14])
 AC_DEFINE(COPYRIGHT_YEAR,["1996-2024"],[Copyright Year])
 AC_CONFIG_SRCDIR(global/global.c)
 AC_CONFIG_HEADERS([config.h:config-h.in])
+AC_CONFIG_LIBOBJ_DIR([libglibc])
 AC_CONFIG_MACRO_DIRS([m4])
 AC_PREREQ(2.71)
 AM_INIT_AUTOMAKE([1.9.3 gnu subdir-objects])
@@ -189,7 +190,7 @@ dnl 	;;
 dnl esac
 dnl  end of gtags-cscope ###
 
-AM_CPPFLAGS='-I$(top_srcdir)/libparser $(LTDLINCL) -I$(top_srcdir)/libutil -I$(top_srcdir)/libdb -I$(top_srcdir)/libglibc -I../libutil'
+AM_CPPFLAGS='-I$(top_srcdir)/libparser $(LTDLINCL) -I$(top_srcdir)/libutil -I$(top_srcdir)/libdb -I../libutil'
 DBLIBRARY='../libdb/libglodb.a'
 
 dnl
@@ -220,7 +221,36 @@ AC_ARG_WITH(db185-compat,
 ],[ with_db185_compat=no ])
 AM_CONDITIONAL([USE_DB185_COMPAT], [test "$with_db185_compat" != no])
 
-LDADD='../libparser/libgloparser.a ../libutil/libgloutil.a '$DBLIBRARY' ../libglibc/libgloglibc.a'
+LDADD='../libparser/libgloparser.a ../libutil/libgloutil.a '$DBLIBRARY
+
+AX_FUNC_GETOPT_LONG
+
+AC_MSG_CHECKING([whether included regex is requested])
+AC_ARG_WITH([included-regex],
+  [AS_HELP_STRING([--with-included-regex],
+[use included GNU regex library])],
+[], [with_included_regex=check])
+AC_MSG_RESULT([$with_included_regex])
+if test ! ."$with_included_regex" = .'yes'; then
+AC_CHECK_FUNCS([regcomp],
+  [with_included_regex=no],

Re: Patches for Fedora 42 & 43

2025-10-13 Thread Collin Funk
Shigio YAMAGUCHI  writes:

> Got it, thanks for the advice.
> I use the latest packages and try not to tinker too much.

No problem. Let me know if you need help. I am a committer in Gnulib. Or
you can send mail to [email protected].

I don't know CVS that well, though. So that will slow me down a bit. :)

Collin



Re: Patches for Fedora 42 & 43

2025-10-13 Thread Shigio YAMAGUCHI
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  wrote:
>
> "Andrew L. Moore"  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 
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB



Re: Patches for Fedora 42 & 43

2025-10-13 Thread Collin Funk
"Andrew L. Moore"  writes:

> We already have one vote in favor of importing Gnulib using its
> provided bootstrap script.

I didn't vote. I will leave that decision up to the maintainer. :)

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

You can still use it from Gnulib. Only the hash-pjw name is deprecated:

$ gnulib-tool --extract-notice hash-pjw
This module is deprecated. Use the module 'hashcode-string2' instead.

$ gnulib-tool --extract-file hash-pjw

m4/00gnulib.m4
m4/zzgnulib.m4
m4/gnulib-common.m4

$ gnulib-tool --extract-notice hashcode-string2
$ gnulib-tool --extract-file hashcode-string2
lib/hashcode-string2.h
lib/hashcode-string2.c
lib/hash-pjw.h

m4/00gnulib.m4
m4/zzgnulib.m4
m4/gnulib-common.m4

Collin



Re: Patches for Fedora 42 & 43

2025-10-13 Thread Collin Funk
"Andrew L. Moore"  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



Re: Patches for Fedora 42 & 43

2025-10-13 Thread Shigio YAMAGUCHI
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  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  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 
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB